Thinking inside a bigger box - Latest Comments in The Joys and Sorrows of Exceptions

Re: The Joys and Sorrows of Exceptions

Johannes Brodwall — Sun, 22 Apr 2007 12:22:54 -0000

Good questions, Casey.

We have created subclasses of RuntimeException for SystemException and ApplicationException (should've been InvalidUsageException). Everything that is not classified is a "bug". Out top-level interceptors which log, retry etc. use this to decide the log level and retry strategy.

I don't think the categories I propose have been used as such in any open source project. However, I think one of the best things about the Spring Exceptions, is that they allow you to decide what sort of a problem it was.

DataAccessResourceFailureException tells you that the database or network is down, InvalidDataAccessUsageException tells you that the client code did something wrong, OptimisticLockFailureException is not actually an error at all (and my categories don't include it). In JDBC, these, and more, were lumped together as SQLException.

I guess what I am trying to say, is that as far as I know, the categories I propose are more a description of why I think Spring has good exceptions than it is a description of what they've done.

Re: The Joys and Sorrows of Exceptions

Casey Mullen — Fri, 20 Apr 2007 21:04:00 -0000

I just read "Practices of an Agile Developer" as well, and the categories do sound useful... although I am not sure how to practically express the categorization of a given exception. If i'm the thrower, I could throw my own "categorized" exception, but what about exceptions emanating from some other library?

Does anyone know of any practical (open source?) project that has made practical, explicit use of these (or similar) categories? Or are these categories more theoretical than practical?

Re: The Joys and Sorrows of Exceptions

Bjørn Bjerkeli — Mon, 21 Aug 2006 06:48:56 -0000

Good writeup Johannes, what could be interestning as well is to add some practical examples related to common mistakes.

I often encounter the issue programs failing to establish a proper context in programs that raises exceptions.

Establishing such a context is trivial, but often omitted rendering the code much more difficult to debug. consider the following example of an instance method in an Account class:

public void validateAcount() {
if (isOverdrawn()) {
throw new IllegalStateException("Account is overdrawn, balance ["+getBalance()+"], limit ["+getLimit()+"]");
}

}

compared to the following version that has context (given a proper toString() implementation):

public void validateAcount() {
if (isOverdrawn()) {
throw new IllegalStateException("["+this+"] is overdrawn, balance ["+getBalance()+"], limit ["+getLimit()+"]");
}

}

Re: The Joys and Sorrows of Exceptions

Johannes Brodwall — Thu, 17 Aug 2006 10:14:56 -0000

Hi Sergio,

Thanks for the comment. I agree with you that business exceptions deserve a whole post of its own. I would really appreciate feedback on what you'd like to read about in such a post.

There are two types of exception handling strategies that I could explore more fully: Things like retrying, failing to another node or mechanism and such strategies, mostly for resource exceptions. Then there is "what to do when you get an AccountOverDraftException, NumberFormatException, AuthorizationFailureException etc." I assume it is the latter you are refering to?

~Johannes

Re: The Joys and Sorrows of Exceptions

Sergio Bossa — Tue, 15 Aug 2006 17:17:50 -0000

Hi Johannes,

thanks for your good write up about exception handling, IMHO a very hot argument.

However, what you miss is IMHO how to deal with business exceptions: a very important question that may deserve a whole post ;)

Probably they are those exceptions you say "you are required to deal with" ... I'd like to know more from your opinion and experience.

Cheers!

Sergio B.