email article printer friendly get the code

Streamline Your Exception Processing
Make applications easier to maintain and support by implementing exception handling at an application level
by Derek Ashmore

May 2003 Issue

The primary reason exceptions exist is to produce and report information about an error and the circumstances in which it occurred. (Consider my liberal use of the word "exception" to be a generic term for any type of object that extends java.lang.Throwable.) Ideally, that error information should be clear and explicit enough that development staff can reproduce the error or an end user can correct his or her behavior. The only other reason I've seen to throw exceptions is to interrogate the stack trace. However, the Java Development Kit (JDK) 1.4 provides a more straightforward approach to interrogate the stack trace.

As a consultant and technical architect, I've seen many exception-handling strategies. Some practices that make exception handing easier to understand, read, and maintain are applicable to all types of applications—for example, Enterprise JavaBeans (EJBs), Web services, Remote Method Invocation (RMI) services, Common Object Request Broker Architecture (CORBA) services, or client applications. First I'll discuss those directed at developers and then those appropriate for architects. (See the sidebar, "Exception-Handling Recommendations for Developers" for a complete list of the developer-focused recommendations.)

Figure 1. | Exception Class Hierarchy

Exceptions are generated using the throw keyword in Java. The object thrown must have java.lang.Throwable in its ancestry. The two most popular extensions of Throwable are java.lang.Exception and java.lang.Error. Exceptions that have RuntimeException or java.lang.Error in their ancestry are called unchecked exceptions. All other exceptions are called checked exceptions. The handling of unchecked exceptions is slightly different than that of checked exceptions. Take a look at an example of using a throw keyword
(see Listing 1), and then take a look at a UML diagram showing the inheritance structure of Throwable, Exception, Error, and RuntimeException (see Figure 1).

Methods that throw checked exceptions must list the exceptions thrown in the throws clause in the method signature. In general, any call to a method throwing a checked exception must be encapsulated in a try/catch block or list the exceptions thrown in the throws clause in its method signature. There are no requirements for unchecked exceptions to encapsulate calls to them in try/catch blocks or to list them in the throws clause.