In programming eventually we run into times when the un-expected happens. These unfortunate times are when exceptions are raised. Normally exceptions should be reserved for exceptional circumstances; however, there are times when exceptions don’t completely break the bank. In fact, sometimes they are expected and lead to bigger problems when trying to handle them.
Let’s look at the following example which attempts to determine if a
valid or not.
It turns out that
URI.parse will raise a
URI::InvalidURIError if the
argument passed to it is not valid. This code uses that fact to rescue the
exception and return false for this case.
While I don’t personally like this kind of code much to begin with, I can see
where it has a time and place. Perhaps one of the most serous problems with
this is other things can go wrong that would go unseen. Let’s assume that
URI.parse attempts to cast it’s argument as a string before parsing it. And
then lets assume we have a model that fits into that with some lazy loading.
We now have an opportunity for our database connection to fail, and instead of
halting our program with a database exception
is_valid_uri? will instead
return false. This is the biggest danger of swallowing errors, but luckily you
can be a little bit more cautious. Instead of just blindly rescuing exceptions,
rescue only what you expect.
It may not seem like much; but trust me, it can save you hours of debugging code!