Exceptions in Java are your friend

Exception handling is one of my pet peeves as I believe it's essential for building robust applications. In an enterprise environment with its short development cycles, it's not only about deploying high-quality software, but also, in the unfortunate reality, about finding bugs in production code as quickly as possible. And that's where correct exception handling helps a lot.

In Java there are two types of exceptions: checked and unchecked ones. The former need to be declared or caught explicitly in the code, the latter remain invisible until they are caught somewhere in the call stack. If uncaught, they just terminate the program.

There's a lot of discussion about if checked exception make sense at all or if they just pollute the code. I do believe they make a lot of sense, if used correctly. Unfortunately in third party libraries and even in the Java runtime that's often not the case. But here's how they should be used:

• Checked exceptions signal a condition that can and will happen during normal program operation and that needs to be handled somehow. The application is able to recover.


• Unchecked exceptions should be thrown id an unexpected error occurs. The application cannot recover and needs to shut down or - more often - cancel the request and show a generic error message. Those errors stem from bugs and system issues.

This categorization applies per component or API. An application usually is composed of many components and hence the meaning of exceptions can change as they are thrown up the call stack. For example, every JDBC method throws a checked SQLException. From the (narrow) view point of JDBC this is justified with the fact that databases are external systems that can be unavailable, not configured correctly. Also much of the data that is passed to the database is unverified and may lead to an error once it hits the database engine.

For an database-driven enterprise application a SQLException most likely is unrecoverable and should be wrapped into a unchecked exception (I use a UnexpectedException for this purpose). For a database query tool, where the user enters SQL, the same exception is a business exception and should be reported to the user in a nice error message. In most cases you would still wrap it, but into another checked exception.

But why dealing with checked exceptions at all? Because they force the developer to think about the fact that things can go wrong right at the place where they can go wrong. Because it not only matters which exception is thrown, but also where it is thrown. For example, a FileNotFoundException can just mean that the user entered an incorrect filename, or that an essential configuration file could not be found because the hard disk is corrupted.

Unchecked exceptions tempt to have a central exception handler, for example a error page configured for the web container. But in many cases the message attached to the exception doesn't really tell what actually went wrong and dumping the stack trace is not very user friendly (and has some negative security implications as well).

But by handling a checked exception when it actually happens, makes it possible to react in a meaningful way (just never do this), even it's only by wrapping it into a another exception with a explanatory, custom error message. Whoever has to analyze a logfile in order to fix an urgent production issue will thank you big time.