Joel On Exceptions : Just Say No

October 13, 2003 · 10 Comments

Joel rails against exceptions in his latest blog entry which I find both surprising and disappointing. Normally, Joel has a lot of good insights but this post is way off the mark in my opinion. Exception handling has been added to most modern languages because the old approach - advocated by Joel - of returning error codes from functions creates ugly code and makes it hard to follow the 'successful' flow of the application. If a function has to return success / failure, then it can't also return a result value unless you either return a structured result (containing the success / failure code and the result - if successful) or you must always pass a result variable by reference as a function argument (something not even possible in every language). The trouble with error code returns is that nothing forces you to check them - you can always go straight to the result variable (because it "can't possibly fail in this case"). Your code ends up totally overrun with code to check error code returns and you can't see the straight line code any more...
By contrast, exception handling lets you cleanly abstract out the error processing. You can write simple, neat code that deals with the straight line case and bookend it with any necessary error handling (using try/catch). You don't even need to be aware of some error conditions - you can leave them for your caller to handle because your code just simply might not be able to do anything useful with the error anyway. Exception handling reduces coupling between components and lets you improve cohesion and reuse - because error handling doesn't have to be inherent to every single component you write.

View count: 147

Tags: programming

10 responses so far ↓

1 Andreas Ryge // Sep 8, 2004 at 5:04 PM

The company I work for, uses the approach Joel advocates, and I must say, that it's a real pain to work with - And it doesn't handle the errors that can occur when working with pointers. Most of the errors that you really want to catch, can't be cought this way. I too, was disapointed reading Joels blog entry.
2 Dominick // Sep 8, 2004 at 5:04 PM

I think the try/catch is very helpful. You can extend exception classes, and even if you don't catch something, it will go up the chain and eventually be caught by the compiler i believe.
3 Christian Cantrell // Sep 8, 2004 at 5:04 PM

I completely agree with this post. I can't understand it when programmers approach exceptions as though they are an inconvenience. I think exceptions in general are a very useful and elegant way of gracefully handing errors and bullet-proofing your code. Exceptions are our friends. We should embrace them!
4 Hefin Jones // Sep 8, 2004 at 5:04 PM

Exception handling does indeed help in writing simple, neat code. However, from experience of working with development teams using C++ exceptions for performance critical applications, I would advise that they only be used for truly exceptional errors. Exceptions often result in unexpected and highly expensive error handling when used by developers who aren't highly skilled in their use. In most cases I would rather see, review, support, and maintain, code littered with traditional error handling rather than exceptions.
5 Scott Keene // Sep 8, 2004 at 5:04 PM

Well, this is right up my alley lately! I agree that it is a bit disappointing to see this post, but it's not an uncommon opinion. It actually made me laugh my ass off for two reasons. One, because of the alternative suggested, which you spoke on very nicely, Sean. But mostly due to the fact that I have spent LOTS of time lately wrangling with exceptions, only to come out on the completely opposite end of Joel - firmly in support of them! But for a counterpoint on the issue, here is an Artima interview with James Gosling on the very same subject: <a href="http://www.artima.com/intv/solid.html">http://www.artima.com/intv/solid.html</a>
6 Steven Johnson // Sep 8, 2004 at 5:04 PM

Yeah. This is the first time I've ever substantially disagreed with one of Joel's code-related articles, but MAN is he wrong on this one.
7 Kwang // Sep 8, 2004 at 5:04 PM

Wow. He must be smoking some strong stuff there. Mind you, it _is_ somewhat annoying in Java how developers don't really deal with exceptions by using the "throws" statement everywhere. From that point of view, I can sorta see where he's coming from.
8 Jason Clark // Sep 8, 2004 at 5:04 PM

I agree that exceptions should be used when you can't recover from the error being trapped, but I disagree that you should use them everywhere (if that's what was meant). Maybe a bit of clarification on what you consider an error? Numerous performance documents on just about every major language out there state that you should use exception handling when you cannot recover from the error. Using exceptions to handle mundane errors (in my opinion) is a waste, as exception handling *can* be expensive on performance. You can write a decent error handling infrastructure without throwing exceptions. Using exceptions is an architectural choice that should be made carefully and used when required, not just to make code "pretty".
9 seancorfield // Sep 8, 2004 at 5:04 PM

Jason makes a good point: overusing exceptions is a recipe for disaster (and a very slow program!). For example, many 'errors' are really expected conditions (like end of a collection when iterating or end of file when reading data) and should be handled directly in the code. Exceptions are for... well, exceptional situations... where you can't always predict whether or not you'll get an error. The real win for exceptions is being able to write error-neutral code in intermediate layers - the low-level code can throw errors (because it has no idea how the application wants to handle them); the intermediate-level code mostly doesn't care about errors; the high-level (application) code knows what to do about errors. (Yes, this is a bit of a simplification but many applications are layered like this)
10 Jon Hart // Sep 8, 2004 at 5:04 PM

Incorrect use of exceptions leads to very hard to read code. The rule of thumb is "If you know its going to happen, its not an error." That means that parsing lines, and using exceptions to catch the end of line is bad. Looping over arrays and using an exception to catch the end is bad. Accessing an object and using an exception to catch a NULL pointer is good.

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...