Exceptional practices, Part 1

Use exceptions effectively in your programs

By Brian Goetz, JavaWorld.com, 08/03/01

Read the whole series on exception handling:

• Part 1: Use exceptions effectively in your programs
• Part 2: Use exception chaining to preserve debugging information
• Part 3: Use message catalogs for easy localization

Using exceptions correctly entails looking at error conditions from several perspectives -- from the perspectives of the class that throws the error, the classes that catch the exception, and the poor user who has to deal with the results. To write friendly programs, you must consider error conditions from all these points of view.

Consider this simple exception class and a method that throws it:

package com.me.mypackage;
public class ResourceLoadException extends Exception {
  public ResourceLoadException(String message) {
    super(message);
  }
}
...
public class ResourceLoader {
  public getResource(String name) throws ResourceLoadException {
  ...
}

When the getResource() method throws a ResourceNotFoundException, it communicates three important pieces of information:

• The kind of exception that occurred (in this case, a ResourceNotFoundException)
• The location where the exception occurred, in the form of a stack trace contained within the exception
• Additional information about the exception, in the form of the message string

Each piece of information will prove important to different recipients. The exception type is important primarily to the classes that called getResource() so the caller can catch certain exceptions and ignore others. The stack trace is significant only to the developer or support technician who may have to isolate or debug the problem. Finally, the message string is most meaningful to the user who must interpret the error message or error log.

When you throw an exception, you should ensure that all recipients receive the information they need to proceed effectively. That means you should throw an exception of the right exception class so that callers can take the appropriate corrective action, and you should generate useful diagnostic messages for users so that they can understand what happened if the program doesn't handle the exception.

Write sensible throws clauses

The set of exception types thrown by a method is an important element of a class's design. When writing a throws clause, you should consider the exception types thrown by a method from the perspective of the method's callers rather than the class's own perspective. What types of exceptions will callers be able to handle sensibly, and what types will they likely just pass on to their caller or to the user?