
The Old New Thing : Cleaner, more elegant, and harder to recognize - Anon84
http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx
======
gruseom
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.

------
markessien
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?

~~~
wvenable
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.

~~~
gruseom
_Exceptions cannot be ignored_

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.

------
MaysonL
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.

------
windsurfer
Yes, he makes a good point. Writing good code is hard. I suppose even for him:
[http://validator.w3.org/check?uri=http://blogs.msdn.com/oldn...](http://validator.w3.org/check?uri=http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx)

1135 Errors according to w3c. Yes, may not be relevant or important, but I
think it's interesting.

~~~
shadytrees
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.)

