This is a good post about error handling and exceptions. I think the title should be changed to reflect that, as I almost didn't bother reading it.
I've slowly but surely gravitated away from using exceptions over the years, for different reasons than the author lays out (though I recognize some of what he's saying from my own experience).
I think the reason exceptions became popular is actually a psychological one: they are easy for the programmer. (I mean the programmer throwing the exception, not the poor sod who has to deal with it, which may be the same person of course.) You hit something you don't want to deal with? Just throw it. It's like the kids' game Hot Potato.
Ultimately, users pay the price for this evasion of responsibility, since they end up with a system that behaves erratically in cases that don't fit the happy path and is hard to understand. In the worst case, the exceptions are just thrown all the way up and the user ends up having to catch the hot potato. (Edit: you can generalize "user" here to include any programmer writing code that calls the original code.)
What I think is going on here is that programming is hard enough without error handling, and error handling makes it harder still. Good error handling models are dependent on the specifics of the program in question - they need to fit the contours of the system and of the domain itself. This is hard, so we don't want to do it, and since we can get away with deferring it, we do.
If you take a look at the author's examples, the code snippet he describes as "not bad" is the only one that attempts to handle the error in place. It's also the ugliest and by far the most complicated-looking. But the complexity is latent in all the other examples too. It's just deferred.
If I am writing code on a project that uses exceptions, I'll use exceptions. If I'm writing my own code, I won't. Exceptions force people using your code to also add exception handling into their own applications. It's an intrusive error handling method, and this is one of the reasons I don't use it.
Did anybody ever prove scientifically or statistically that exceptions offer clear advantages over return-type error handling? Who decided that exceptions are the path for all programmers to follow?
Return-type errors force people using your code to also add error checking into their own applications at every call. It's an intrusive error handling method, and this is one of the reasons I don't use it.
The clear advantages of exceptions over return-type error handling is:
- Exceptions cannot be ignored, error codes are ignored by default.
- Exceptions can (and do) contain significantly more information about the error. Stack traces are typical but since exceptions are objects they can contain any amount of extra information. Error codes are typically integers. Sometimes they're just negative integers.
- Exceptions free-up the return of functions for useful results. You can call functions as parameters: readAll(OpenFile(GetFileName())).
Pretty much any negative practice regarding exceptions apply equally to error codes.
Yet they routinely are, or they are "handled" using a top-level catch that allows for no meaningful action and is little better than throwing the exception to the user.
Error codes are typically integers.
There's no reason why an error can't be an object.
Exceptions free-up the return of functions for useful results.
The practice I currently favor is to represent errors as objects of the same type the function returns, objects that represent something meaningful about the error. Of course this isn't always possible and in any case requires good design. There are a lot of advantages to it, though.
Pretty much any negative practice regarding exceptions apply equally to error codes.
Except the one big problem with exceptions, which is the transfer of control out of context.
I quit reading when he said recogninzing bad error-code-based code is really easy, and that recognizing not-bad error-code-based code is hard. DOES NOT COMPUTE. A or ~A, for goodness sake.
If I remember correctly, the MSDN Blogs software is written for all the blogs, and it's not written by Raymond Chen.
(Also, counting the number of errors as a statistic is tricky: It looks like that blog theme was designed for HTML, not XHTML. That would account for a large majority of the errors.)
I've slowly but surely gravitated away from using exceptions over the years, for different reasons than the author lays out (though I recognize some of what he's saying from my own experience).
I think the reason exceptions became popular is actually a psychological one: they are easy for the programmer. (I mean the programmer throwing the exception, not the poor sod who has to deal with it, which may be the same person of course.) You hit something you don't want to deal with? Just throw it. It's like the kids' game Hot Potato.
Ultimately, users pay the price for this evasion of responsibility, since they end up with a system that behaves erratically in cases that don't fit the happy path and is hard to understand. In the worst case, the exceptions are just thrown all the way up and the user ends up having to catch the hot potato. (Edit: you can generalize "user" here to include any programmer writing code that calls the original code.)
What I think is going on here is that programming is hard enough without error handling, and error handling makes it harder still. Good error handling models are dependent on the specifics of the program in question - they need to fit the contours of the system and of the domain itself. This is hard, so we don't want to do it, and since we can get away with deferring it, we do.
If you take a look at the author's examples, the code snippet he describes as "not bad" is the only one that attempts to handle the error in place. It's also the ugliest and by far the most complicated-looking. But the complexity is latent in all the other examples too. It's just deferred.