Letters to the Editor

Readers debate the value of enums, propose an additional advantage to EJB, and comment on exception-handling practices

1 2 Page 2
Page 2 of 2

Brian Goetz

More exceptional practices

Brian,

Thanks for a tremendous series on exception handling. As a lead developer, I have asked all my junior developers to read this series. Too often, exception-handling by even experienced developers is ignored or misused.

I have some comments about Part 3: You should have stressed more the use of properties files to hold the message catalog, as this approach truly separates the text from the Java code -- as opposed to the messages being in a ListResourceBundle.

Secondly, I have discovered two extreme views with exceptions: One extreme is the developer who maintains an almost flat exception hierarchy and then has many messages in the message catalog. While this means fewer classes to develop, often the client code starts having to peek at the message key to determine the appropriate action to take. On the other extreme is the developer who wants an extremely large hierarchy and feels that the type (class) of the message itself should indicate all message meaning. This tends to lead to an explosion of exception classes. There is a middle ground that features enough of a hierarchy where client code does not have to use the message key to take action -- of course, you can't always know how an API will be used.

Bill Siggelkow

Bill, I tried to avoid the topic of where the messages live -- you could use

ListResourceBundle

or

PropertyResourceBundle

-- the effect is the same. While

ListResourceBundle

s are still classes, they contain nothing but resource strings, so the

ListResourceBundle

source files can be owned by the document writer -- and that's the important thing. Actually, the two exception views are pretty much orthogonal to the question of whether or not you have to peek at the message text/key. Whether you have a flat hierarchy or a deeply branching hierarchy, the real question is whether you have enough information embedded in the type to identify the exception, which basically translates to "How lazy were you about making enough exception classes?" One technique I've used, which some dislike, is to group related exception classes as static subclasses:

public class Holder {
   public static class FooException extends Exception {
   }
   public static class BarException extends Exception {
   }
}

You now have the ability to put related code in the same file. Brian Goetz

1 2 Page 2
Page 2 of 2