Exceptions Mini-Lecture – Part 3
October 22nd, 2008
Exceptions are actually just a subset of all of the things that can go wrong in a Java application. There is a distinction between exceptions and errors. These two concepts collectively are modeled through the Throwable class.
Throwable
At the root of the error class hierarchy is the Throwable class. This sits above both errors and exceptions. As such, it is possible to have a catch block catch Throwable. This is typically not correct, for reasons we will see in discussing errors below. However, there are times when the caller would want to prevent any sort of error from bubbling up. In such cases, catching Throwable will prevent any errors at all from bubbling up the call chain.
There are two direct subclasses to Throwable that model the error distinction in Java: Exception and Error.
Error
As taken from the Java API: “An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.” Put another way, errors are generally things the application cannot hope to recover from. As such, it’s generally a bad practice to catch an error, since a catch statement indicates a recovery from an error condition.
One example is the OutOfMemoryError. There is little the application can do to recover when the virtual machine runs out of memory. Therefore, it is usually best to let this error bubble up to the calling method to be treated as a bug.
Exception
Much more common are exceptions, which represent a state that can likely be recovered from by the calling method. For example, a FileNotFoundException is not fatal to the program; the calling code can reprompt the user for the file name. Similarly, an IOException is likely not a fatal error either; the connection can be attempted again after a set period of time or after some configuration changes.
Exceptions are divided into two different types:
Checked
A checked exception must be handled at compile time. As per the first part of this series, handling a checked exception can be down by declaring the calling method throws the exception up to its caller or by catching the exception in a try/catch block.
Unchecked
Unchecked exceptions do not explicitly need to be handled. They may still occur, however the calling method does not have to provide a means for handling them. The calling method may catch an unchecked exception like any other, but it is not required.
Unchecked exceptions are all exceptions that are subclasses of the RuntimeException class. The RuntimeException class itself is a subclass of Exception. Thus, I typically have been saying “most” exceptions when referring to checked exceptions, while this small subset of the class hierarchy below Exception are considered unchecked and behave slightly differently.
