Hey, I am just so glad someone agrees with me. I read your rticle and got all nervous because I am so clearly out of touch with the times, so it is a relief to see someone else who objects to exceptions. Even if the site was hacked, I agree with the hacker.

Geez Louis, Joel is so wrong here! It's really an "old school" argument to favor return codes over exceptions. Return codes *do* work when used carefully but exceptions are a superior mechanism.

I used to work with an old school C programmer who insisted on using K&R style C function declarations. He'd been writing C code since Bjarne Strostrup was in short pants. He wasn't about to change. His code was extremely well written and careful as hell but just try to get someone else to even touch it.

Agreed--Spolsky is a smart guy, but he's also extremely pedantic sometimes. I really don't see any problem with exceptions, and have employed them quite effectively in my own code.

Exceptions are a "bring to the mean" mechanism.

Error checking is vitally important, yet poor programmers traditionally don't do it. Exceptions make it easy for them to do error checking in a minimally acceptable way, which is a great improvement over what they would do otherwise.

However, exceptions make it more difficult for competent programmers to write truly excellent error checking code. Sure, they too can easily write decent error checking code with it, but to write excellent code, they have to treat the exceptions just like status returns - catch every possibility after every call.

Most programmers are not very good. So, all in all, exceptions are a good thing, overall. But don't pretend that they're superior to status returns when in the hands of the competent.

person: I don't agree that exceptions make it more difficult to write decent error checking code. In fact, exceptions can provide more context for error reporting -- since they're classes, not just status codes.

The one key distinction between exceptions and error return codes is that exceptions are less easily ignored. You either have to catch the exception and deal with it or some other code that calls you will. Ignoring a return value from a function is just too easy.

Also in languages such as Java and C#, being able to get access to a stack trace in an exception catch block is truly wonderful.

Bob's last point is especially pertinent I think: Java is my first "proper" programming language, so I've always taken e.printStackTrace() for granted when in debug mode...

However, given that other languages don't necessarily provide that kind of info as easily, that alone is a good reason for carefully constructed exceptions.

Just as there are poor examples of OO design, there exist examples of poor exception handling (given that exceptions are objects). Blaming the language (or indeed making blanket statements about the "one true approach") rather than the shortcomings of an individual programmer seems a bit daft to me.

Hey Ned, Joel is quoting you now.

http://www.joelonsoftware.com/items/2003/10/15.html

Ball is in your court.

--bob

"I don't agree that exceptions make it more difficult to write decent error checking code."

I didn't say that exceptions make it more difficult to write decent error checking code. In fact, I said the exact opposite - that exceptions make it easier to write decent error checking code.

The problem is that they make it more difficult to write better than decent error checking code.

In a world full of poor programmers, the latter detriment is more than offset by the former benefit - decent error checking code is much better than the error checking code that otherwise would be produced by the average programmer.

But they bring good programmers down to average. That's why I said that they're a "bring to mean" mechanism.

And, I might add, that seems to be the point of the author of the article, as well.

Okay, person, I misread your comments. Sorry. And I see your point but I'm not sure I agree. Even with the approach where function returns error codes, the function has to advertise which codes it might return. Returning a huge list of possible error codes is uncommon. With exceptions, the same is true. And, since exceptions are objects, you can deal with how fine-grained you want to get. For example, catching IOException may be sufficient much of the time but catching a subclass (FileNotFoundException) will be appropriate in cases where you mighyt actually be able to do something about the exception.

The hard part of writing code in the face of possible errors is to handle all of the cases and be prepared to deal with them. Detecting errors is easy, having a plan to deal with them in an appropriate way is much more work.