Annotated Exceptions

On the topic of exceptions, one of my pet peeves with most exception based error handling code is that it misses the opportunity to capture more information about the problem. Ned references the capability of exceptions to carry more information in his essay and specifically mentions Java 1.4’s exception chaining capability but doesn’t go any further with the idea. Knowing the full call stack is fantastic but what if you also knew the parameter values of the function that threw the exception or if like most server based apps you’re logging your exceptions, how about capturing the version information, thread id, memory and disk space status too?

Probably the main reason people don’t do this in Java is because the Exception class doesn’t provide any default mechanism for storing extra data. To that end I wrote some new Throwable base classes for my project at work that allow arbitrary annotations to be attached to an exception before it’s thrown. (I call them AntException, AntRuntimeException, etc….). Not only can I annotate the exception with contextual data, I can mimic the Java 1.4 feature of chained exceptions in Java 1.3 by annotating an exception with another exception.

The problem is that most people are thinking about the non error path when they write the code and not about how they will debug a post-mortem problem in the code from a log file. A very simple case of how doing this little extra work has helped is this story. I work on a very large team spread literally across the world. On any given day there are people running any of a half dozen builds from the past week. As exceptions show up in the log, folks capture the log fragments and write bug reports (or Software Problem Reports as we call them). One very simple thing we did to make this information more valuable was to annotate every exception with a build version number. (Sure the tester should know what version of the code they are running and put that in the bug report, but this eliminates any doubt). So now when I look at an exception dump in a log file I not only know where the problem occurred, but what build it was that had the problem.