Are exceptions a good or bad thing in a language? Joel Spolsky, Anders Hejlsberg and others weigh in.
Joel doesn't like exceptions.
They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.
A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be.
Anders disagrees:
It is funny how people think that the important thing about exceptions is handling them. In a well-written application there's a ratio of ten to one, in my opinion, of try finally to try catch. In the finally, you protect yourself against the exceptions, but you don't actually handle them. ... because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop. That handler is just going to bring up a dialog that says what went wrong and continue. The programmers protect their code by writing try finally's everywhere, so they'll back out correctly if an exception occurs, but they're not actually interested in handling the exceptions. (quotes re-arranged for my emphasis)
Raymond Chen appears to weigh in against exceptions in Cleaner, more elegant, and wrong, but clarifies a bit with Cleaner, more elegant and harder to recognize:
The title of the [prior] article was a reference to a specific code snippet that I copied from a book, where the book's author claimed that the code he presented was “cleaner and more elegant”. I was pointing out that the code fragment was not only cleaner and more elegant, it was also wrong.
You can write correct exception-based programming.
Mind you, it's hard.
It's easy to write bad code, regardless of the error model.
It's hard to write good error-code-based code since you have to check every error code and think about what you should do when an error occurs.
It's really hard to write good exception-based code since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it. (In C++ it's not quite so bad because C++ exceptions are raised only at specific points during execution. In C#, exceptions can be raised at any time.)
In practice, I've never really worried about it and simply fallen in line with how Anders describes the world and it seems to work out fine, but that's not to say I know what I'm doing.
