Jan. 11, 2005, 10:58 a.m.
IT

When to use checked exceptions and when not to

I guess there would be three groups of Java developers out there - those who know about exceptions but have never heard of checked and unchecked exceptions, those who know what it is but do not understand them and those who truly know and understand them. My educated guess is that most people fall in the former two categories. This article will try and explain the differences between the two kinds of exceptions, as well as when to use which.

In Java the base exception hierarchy as defined in the J2SE API looks as follows:

        Serializable
             ^
             |
         Throwable
          ^     ^
          |     |
   Exception  Error
       ^
       |
RuntimeException

Firstly, since Throwable is at the root of this hierarchy of classes, and only subclasses of Throwable can be thrown by the VM it indicates that all exceptions in Java is serializable (obviously provided all their members are too).

Checked exceptions are defined as any class that is a subclass (descendant) of class Exception, or an instance of Exception itself, but excluding RuntimeException. These exceptions are used to indicate anticipated conditions, such as an account not found in the database, or an invalid user input etc. It is important to note that all checked exceptions needs to be declared in the throws clause of each method that might throw that exception, or it must be caught in a try-catch block and handled. The reason for this is not to make your life difficult, it is there to help you anticipate, understand and handle expected, recoverable situations. Maybe I should just re-iterate that point - checked exceptions are intended for recoverable situations. You will make your life miserable (and those of the other developers in your team) if you throw unrecoverable conditions as checked exceptions. What good is it to force someone to catch something (or even know about its existence) if there is nothing the caller can do?

Unchecked exceptions are defined as any class that is a subclass (descendant) of class Error or RuntimeException, or an instance of one of those classes themselves. These exceptions are used to indicate unanticipated conditions, such as a database failure, unexpected communication problem encountered etc. It is important to note that unchecked exceptions neither need to be caught by methods that throw them, nor do they have to be declared in the throws clause. These exceptions will "fall through" until it is handled by either an outer level try-catch block (such as those found in Tomcat, JBoss etc.), or by the Java runtime interpreter itself, in which case the application will be terminated. Unchecked exceptions are intended for any abnormal or unanticipated condition that cannot reliably be handled by the caller. The idea is to have a mechanism in place whereby you can "fall through" from an innermost method call, unwinding the stack right to an outer layer that can handle the error without having to force developers to know about that exception's existence and not forcing them to handle or declare it.

It is clear from this discussion that there is a very valuable use of both kinds of exceptions, if used properly. Always remember - use checked exceptions for anticipated, recoverable situations that developers need to explicitly handle or declare, and used unchecked exceptions for unanticipated, unrecoverable situations that developers cannot handle and need not handle or declare.