Alway handle errors locally? That seem to break both modularity and abstraction.

Consider a module that does some IO. The module might be used in different kinds of apps, both GUI apps, services and command line apps. How should this module handle a "disk is full"-error? Should it show a dialog with a warning, or write the message to the console and die? The appropriate action would be completely different depending on the type of app and the context wherein the module is invoked.

Exceptions allows the module to delegate the error handling to the right level of abstraction.

Sigh... Obviously errors should be able to propagate up the call stack. But that propagation needs to be done explicitly. Simply tacking "throws IOException" onto your function header isn't enough; it's still too easy to mess up.

I can mess up anything, but I don't really see how it is easier to mess up exceptions than explicit propagation of special values.

You need to do the explicit propagation after every single line that might generate an error. That seems to me to lead to a lot of boilerplate code, and it would be easy to forget or mess up one of these lines.

I kind of see Joels point though, that if you write:

    openFile();
    doSomething();
    closeFile();

Then it is not obvious by just looking at these lines in isolation, that the file may not be released. If you already have the throws clause in the signature for some other reason, you might miss this. I don't think boilerplate error handling is the right solution for this though. Boilerplate just gives you boilerplate-blindness.

A language for programming nuclear devices like Joel hints at, might make the throws clause explicit on every method call:

    openFile();
    doSomething() throws IOErrors;
    closeFile();

(Don't know if any language has this syntax, but at least it makes the throw obvious in a much safer way.)

However I prefer something like the using pattern in C#:

    using (file) {
        doSomething();
    }

(Same as "with" in python.) I find this the ideal solution, since you don't have to worry about whether the method may throw exceptions at all, the file will always close correctly. And regardless of exceptions, the syntax guarantees that you don't forget to close the file.

Let me give you a real example from a program I worked on. I'll simplify the code.

Say you write a function that takes input given by the user, inserts it into a list, and then sends the action across the network. Every item has an ID, so when the function finishes, the current ID number needs to be incremented.

 add_item (item) {
     var item_id = current_id;
     insert_item(item, item_id);
     update_current_id();
     send_item(item, item_id);
 }

You write the function, and it works, and no one has any problems with it.

Two months later, you come back to the function and think, "That's messy. I should clean that up." So you do.

 add_item (item) {
     insert_item(item, current_id);
     send_item(item, current_id);
     update_current_id();
 }

Do you see a problem with this code? No, you don't. You even run the program and try it out, and everything seems to work fine.

What if the function header had said "throws NetworkException"? You might have been more careful, but I wouldn't count on it. If the function were longer, which it would be in real life, you probably wouldn't catch your mistake.

On the other hand, what if the code looked like this?

 add_item (item) {
     if (insert_item(item, current_id) == INSERT_ERROR) {
         return INSERT_ERROR;
     }
     if (send_item(item, current_id) == SEND_ERROR) {
         return SEND_ERROR;
     }
     update_current_id();
     return SUCCESS;
 }

Do you see the problem now? Of course. It's staring you in the face: current_id won't get updated if the network goes down. The result is that you could have two items in your list with the same ID.

This isn't "nuclear power plant" paranoia. What I'm describing is a real bug I had recently. It wasn't the first time that I've done something like this, either.

I like your idea of putting the throws clause next to the function call. I'd like to see something like that for checked exceptions, and eliminate unchecked exceptions completely.

OK, I think I get get it now. You (and Joel) are right. By reading your comment I realized that I have a number of coding habits that (in most cases) prevents this sort of error from occurring. But that proves your point that exception-based code is harder to get right.

I still prefer to write exception-based code, but I understand how you could prefer to use return values.