To throw or not to throw [was: Go Programming talk [OT]]

[Nick Sabalausky]

"Leandro Lucarella" <llucax at gmail.com> wrote in message 
news:20100609162223.GC16920 at burns.springfield.home...
>
> BTW, here is a PhD thesis with a case against exceptions. I didn't read
> it (just have a peek) and it's rather old (1982), so it might be not
> that interesting, but I thought posting it here as the thread became
> mostly about exceptions and someone might be interested =)
>
> http://web.cecs.pdx.edu/~black/publications/Black%20D.%20Phil%20Thesis.pdf
>

I didn't have time to read the whole thing, but I read the Abstract, 
Introduction, and roughly the first half of the Conclusion. But I did ignore 
all the sections where he yapps on about what a programming language is, 
what their point is and what makes a good one (Maybe in his next paper he'll 
take a stab at P=NP while making sure to explain in perfect detail why 2 + 2 
is 4.)

Regarding what he said about exceptions: Some things struck me as things 
that may have seemed to make reasonable sense back in 1982 when it was 
written, but don't anymore. Other times, the guy seemed completely out of 
his mind.

I did take a [very] brief skim through chapters 5 and 6, though, where he 
explains his alternative to exceptions. I could be wrong, but it looks like 
what he's describing amounts to using algebraic data types and/or tagged 
unions along with having the concept of "error" be a value of it's own 
strong type that works similar to propagated NANs or the propagated "error" 
expressions Walter recently implemented in DMD to improve error-reporting. 
Ie, something like this:

--------------------------------
// Singleton, and vaguely similar to the "null object" idiom.
class Error
{
    public static Error error;
    public static this() { error = new Error(); }
    private this() {}
}

alias Algebraic!(double, Error) doubleOrErr;

doubleOrErr divide(doubleOrErr a, doubleOrErr b)
{
    if(a == Error.error || b == Error.error || b == 0)
        return Error.error;

    return a/b;
}
--------------------------------

I think that's an interesting idea that might be worth looking into. 
Although it would seem to bloat the memory usage and maybe speed of a 
program since just about anything would have to be an Algebraic.

My analysis of what I saw as his main points about exceptions:

In the Abstract:

"The very real problems of survival after a component violates its 
specification [ie, general fault-tolerance] is not addressed by exception 
handling. [(He appears to be talking about things that are addressed by 
redundant systems, watchdogs, fail-safes, etc.)]"

True. But neither do the things exceptions are used to replace. And 
exceptions at least make it possible in a few small cases (moreso than the 
things exceptions are used to replace).


In the Introduction:

"[People think exceptions are a cure-all for program errors. They're not, 
and thinking that they do is dangerous.]"

Maybe there were people making/believing such broad claims about exceptions 
back then, but I don't think anyone does now. It's kind of as if he were 
saying "GC is worse than manual memory management because it makes people 
believe they never have to think about memory management issues". 
Programmers, of course, have already figured out that's not the case.


"On practical grounds, too, exception handling handling seems to be poorly 
motivated..."

The paragraph that starts with that sentence (in the introduction) seems to 
be nothing but a bunch of hand-waving.


"[A compiler that supports exceptions] is likely to be larger, slower, more 
prone to bugs, and less explicit with its error messages."

Probably would have been true in 1982, when the paper was written, but these 
days the difference would be minimal.


"Each nested recovery compartment represents a frame of reference in which 
progressively more disastrous events are anticipated, but progressively less 
comprehensive recovery is attempted."

That's completely dependent on the exception-handling code. What the system 
allows, and he seems to be ignoring, is an in-process version of a watchdog. 
Not as reliable as an out-of-process one, granted, but it can help.


In the Conclusion, under the hading "8.1 Exception Handling is Unnecessary":

"...abstract specifications can be written without abstract errors..."

I'd have to read the chapter he cites to have anything meaningful to say 
about this.


"...a programming language exception mechanism neither prevents the 
construction of erroneous programs nor provides a way of dealing with errors 
that absolves the programmer from thinking about them."

Straw-man. I don't know what the programming climate was like in 1982, but 
I've never heard anyone claim that exceptions do either of those things. 
However, they *do* improve what had ended up becoming a very bad situation, 
so the idea that they're "unnecessary" is, at best, an overstatement.


"[Bugs (ie, cases where the program deviates from its specification)] should 
be corrected before the program is delivered, not handled while it is being 
run."

HA HA HA HA HA!!! (/Wipes tear/) AHH HA HA HA HA HA!!!!

Translation: He seems to be living in lala-bizarro-land where the waterfall 
model produces good, reliable results and one can simply "choose" to find 
all bugs before shipping. Also, everybody is always happy, there is no 
disease, and everyone spends all day frolicking in the daisies, climbing 
rainbows and playing "Kumbayah" on their guitars.

Then there's a big convoluted, meandering three-paragraph rant involving 
illegal states but doesn't appear have any obvious point I can discern. My 
best guess is he's trying to say that exceptions are part of the 
specification of the program, therefore they don't technically qualify as 
actually being "exceptions" at all, which, of course, is just useless 
semantic bickering. But frankly, I'm not sure even he knows what the hell 
his point in those paragraphs is.


"Exception handling mechanisms are unnecessary because they can always be 
replaced by [he lists some other things here]"

A thoroughly pointless pedantic argument as most useful programming language 
constructs can be replaced by other ones. So exceptions can be, too. Who is 
surprised? Who the hell cares?


In the Conclusion, under the hading "8.2 Exception Handling is Undesirable":

"The reason that exception handling mechanisms are undesirable is that, 
whereas they are irrelevant to the correction of erroneous programs, the 
difficulties they introduce are very real."

I really did go into this paper with an open mind, but the deeper I get, the 
deeper the hyperbole seems to get. I can certainly grant that there are 
difficulties introduced by exceptions, but what bugs me is the implication 
that exceptions are undesirable purely because "they are irrelevant to the 
correction of erroneous programs" (and have other drawbacks). There are two 
way you can take that "irrelevant to the correction of erroneous programs" 
part, and either way leads to the argument becoming a big pile of bullcrap:

A. You can interpret it literally and pedantically, in which case it might 
be *technically* true, but conveniently ignores other benefits of exceptions 
(ex, they are relevant *and* useful for managing and mitigating problems 
caused by certain types of programmer/user/system/hardware errors, and for 
keeping high-level intent clear while doing so).

B. You can interpret it more liberally, in which case it's just a plain load 
of hyperbolic crap right at face value.


Then he lists the difficulties he sees exceptions as introducing:

"(i) They permit non-local transfers of protocol, re-introducing the dangers 
of the goto and the problem of clearing up."

The only such things they introduce that aren't already comparable to 
"return", "if", and "while", have been solved by "finally" and scope guards 
(and the occasional RAII helps too).


"(ii) [something about different processes]"

I'm not going to re-type or refute this one as I'm not really sure what he's 
getting at anyway.


"(iii) If "functions" are allowed to generate exceptions, a rift is 
introduced between the concepts of "function" in the programming language 
and in mathematics. This complicates the semantics of the language and makes 
reasoning about programs more difficult."

I don't know about 1982, but I've been programming since the late 80's, and 
as far back as I can remember, the rift between the languages of math and 
programming (particularly imperative) has always been a mile wide. He may as 
well complain that chemical "equations" don't behave the same as they do in 
algebra.


"(iv) Recursive exception handling () is extremely complex."

It's certainly an issue, but I don't know about it being "extremely" 
complex. Things like linked exceptions (ie, an exception with a "next") 
certainly help.


"(v) An exception handling mechanism may be used to deliver information to a 
level of abstraction where it ought not to be available, violating the 
principle of information hiding."

You can violate information hiding with an ordinary function, too. Or with 
pointers. So what? It may make it easier than to accidentally leek some 
information, but I've used exceptions extensively and have never found it to 
be particularly problematic in actual practice. Actually, such problems are 
pretty easy to avoid if you just consider anything you throw to be "public".


"(vi) [checked exceptions are a PITA]..."

Agreed.


"(vi) ...On the other hand, if exceptions are not specified then the dangers 
of using them are increased, and many of the advantages of strong typing are 
lost."

I haven't a clue why he feels the advantages of strong typing would be lost.

As for dangers of using exceptions being increased, that may be true to a 
small extent, but I think he's overstating the dangers. Also, there's 
nothing preventing the creation of a code-analysis tool that checks what 
exceptions can be thrown (directly or indirectly) from each function (in 
fact this has always been one of my arguments against checked exceptions). 
That would provide the best of both worlds.