« OpenOffice to use RELAX NG. | Main | Fatboy stick »

Checked exception still considered pointless

I can't agree with Ross Judson, though I understand where he's coming from. Anders Hejlsberg is not wrong on checked exceptions, though there are other reasons to avoid them.

First, most libraries will declare a general exception class, like LibraryException, and build all their more specific exceptions using subclassing. Most methods will throw a LibraryException, and specialize from there if necessary. Problem solved. You can pay attention to the messages and concrete subclasses if you want to, but you don't have to.

One answer to all this fuss is to throw LibraryException everywhere if all you're going to do with the internal exceptions is cast them into a string/stream objects and be done with it. But, and it's a big but, tying exceptions to packages/components or a service boundary is bad design. Don't tell me something bad happened in the Library, I already know that something bad happened in the Library. Describe what happened in the Library. There's no interest or use for a LibraryException, though there may well be interest and use in documenting the unexpected behaviour in the Library. It's a bit like the comment that tells me what the next line of code does instead of why it does it, an approach we've know for years and years to be silly. Exceptions that say where they come from instead of why they arose are no different to those comments (and if you can replace the useful comment with a useful method name, more power to you).

Exceptions are about understanding behaviour, not structure. After more than 6 years of dealing with other Java folk's checked exceptions, I've concluded the only exceptions that should be thrown at package/namespace boundaries are ones that signify a behavioural issue and preferably one that is already supplied by the language's core libraries (assuming you had a decently designed core libraries to begin with, which is not entirely the case with Java). I'm also coming to the conclusion that clients should have the option to not deal with exceptions and reason against the main line if they wish, rather than be forced to handle a checked exception. Which is an argument for dropping checked exceptions altogether.

Second, chained exceptions are an effective way of dealing with the library combination issue. You capture a sub-library's exception, then wrap it with one of your own. As a library, your use of a sub-library is something that should be transparent to the calling system. Chained exceptions allow you to convey the right information back in a general form.

Chained exceptions are hacking at symptoms instead of solving problems. I should probably explain that. Chained exceptions exist solely to stop dependencies on someone else's checked exceptions bleeding into the dependent's code signatures.This is because (again) exceptions deal with behaviour not structure and as such are intimately tied to control flow not code organization. Without some such trickery, somebody else's exception type will invariably pollute your code, something which is for the most part unneccesary. Checked exceptions are in my humble opinion a mess when it comes to decoupling code. Sort of like hardcoding your debugger's checkpoints into your library and expected to world to be ok with that. I imagine tests are a better way to weed out such issues than punting with exceptions.

Almost everything we do with an checked exception is log it and read it, ie, we cast its message to a string or stream and send it to i/o. We can do that just as well with an informative message in a runtime exception or core checked exception. In my eyes the special case is almost always not a good candidate for creating a new type. Are there special cases that should be identified with a type? No doubt, but I think they're rarer that we imagine. There are only some many things that can go wrong with a computer program and we know about a good number of them already - any further refinement can be dealt with through an exception's message.

The other thing I can do with a checked exception is to move off the main line of control flow, and go execute something else. When I find myself using exceptions to outline alternative paths of of execution, in other words when I want to catch an exception and do something other than log it and continue (or, really I want my caller to do it), I need to stop and admit that I'm coding with GOTOs. What's happening is that I'm using exceptions to intimate that dealing with failure cases and programming away from the main line is an important part of the programming against my library. What I really ought to do is reveal that intent through an explicit protocol that my callers can act upon. Handling exceptions and being clever gets me into trouble more often than not.

Languages that don't check them (which is basically everything else out there) just kind of scare me right now. How do you know you've got everything handled? The answer is...you don't.

They shouldn't scare anyone. As for handling everything - asking to know if we've handled everything is like asking to know about the non-existence of bugs - in short we don't. Sometimes something bad happens in the code and the best thing to do is exit control. If you already know how to deal gracefully with an expected error somewhere in the code (checked exceptions are clearly not unexpected, or exceptional), you can code defensively to that error without a new type.

Not so long ago, Ron Jeffries went head to head with the extremeprogramming list for the best part of a week arguing against exceptions; the list pretty much came up wanting. Checked exceptions don't help much and are best minimized or avoided. But I don't expect to get much traction on that idea. This is how error handling has been done in Java for so long, and it's so idiomatic and reflexive to do things this way, it can be difficult to see what the problem is. Nonetheless, food for thought:

[Alan Griffiths: Exceptional Java]
[Bill de hÓra: Checked exceptions considere pointless]
[C2 Wiki (Robert di Falco): GeneralizeOnExceptionBehavior]
[C2 Wiki (Bill Trost): JavaExceptionsAreParticularlyEvil]


August 30, 2003 02:44 PM

Comments

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1072

Listed below are links to weblogs that reference Checked exception still considered pointless:

» Checked exceptions vs Unchecked Exceptions + Tests from Ted Leung on the air
Bill de Hora is contributing his thoughts to the checked exception debate. His post has some good points As I was thinking about this some more, checked exceptions start looking like explicit typing. The reason people want checked exceptions is t [Read More]

Tracked on August 31, 2003 09:10 AM

» On checked exception - again... from public virtual MemoryStream
Via Ted Leung and Bill De HÓra, I read Ross Judson's comments on checked exceptions. This subject just keeps coming back... I blogged about this half a year ago arguing against checked exceptions. In all honesty, I actually do like checked excepti... [Read More]

Tracked on August 31, 2003 11:42 PM