Effective Java Exceptions
Essentially, it classifies errors in two categories: contingencies and faults. Contingencies are something your application is prepared to handle, so you should use a checked exception (or a special return value, like null) and recover. Faults, on the other hand, are not expected (like not finding the configuration file) and should never happen… so they should be unchecked exceptions.
Ok, so what’s new about this? Everyone seems to be doing that nowadays… starting with the good folks making Spring.
Well, apart from the discussion in TSS about the example chosen in the article, what I found really interesting is that it is the first time that I read someone stating that unchecked exceptions should be caught.
Let’s face it… all those promises that Spring and others make about simplifying your code by forgetting about exceptions (spring’s database classes wrap every JdbcExceptions in a RuntimeExceptions so you don’t have to catch them) is plain false.
Not really… it is just that they usually forget to tell you that you need to care about them at some point. Don’t know about your users, but mine don’t like reading stack traces on their browsers.
Getting back to the article, Barry Ruzek proposes handling them in a common place, near the
user (intercepting the exception before it reaches the view layer). That’s a good suggestion… catch the unchecked exceptions before they reach the user and show them a generic error message, while you log everything in order to provide good support.
The problem with that is that you are far from the reason of the failure. And the article makes another good point in reminding that exceptions are full-blown objects. That’s something easy to forget, as most exceptions are only equipped with a vague text message and maybe a nested exception. What about the information about the context? If you receive a database error while querying the database, maybe you are interested in knowing which query was executing, or the value of the parameters…
So, the conclusions I can draw are:
- Use a subclass of RuntimeException for signaling situations that can, but should not, happen.
- Use a subclass of Exception for signaling expected error situations (the classical example is a bank account without enough funds, but also when the filename the user typed does not exist).
- Make your exceptions rich in information. The user won’t see it, but it can make the difference when trying to find and resolve the problem.
- Always catch your unchecked exceptions, don’t let the user see them. If you are coding a swing application, it’s even worse… you don’t have a server to render the stack trace, so the most probable outcome is that your app dies a silent dead.
Overall, Effective Java Exceptions is a good reading that I recommend.