"Leandro Lucarella" <llu...@gmail.com> wrote in message
news:20100609162223.gc16...@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.
