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

[Jer]

Nick Sabalausky wrote:
> "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

But he noted you 28 years ago. I wonder if that student now has made 
millions of dollars on the web.

> 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,

I don't remember that, but you seem to take offense to it. Should I go 
back and read those parts? (rhetorical).

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

In what you have "said" thus far, makes you look like someone flustered 
that your snakeoil is just what it is. (At least it is the feeling I get 
straight away).

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

As you are obviously flustered and about to go off on a rant, I'll just 
sit back and enjoy the show. ;)

> Other times, the guy seemed
> completely out of his mind.

Oh yeah, now you sound "objective"! LOL!

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

[blah, blah and Walter]

Nuff said, no comment to your affiliations. I hear that "grouping" is 
"good".

> 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.)]"

No, he refers to such. Hello. We're all "big boys" here. We know about 
real-time systems concepts (though most of "us" are probably (?) not 
real-time systems programmers). Don't read "advanced" material if you are 
oblivious to it and then comment on it. Nor use it as a vehicle to show 
you know the elements of it. Nuff said: stop wasting bandwidth with your 
personal issues.

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

The point, may have been, and surely was (like I have time to read such a 
WORDY thing word-for-word, mind you), that a LARGE amount of complexity 
is not justified for incremental and debatable gain. You seem to be 
playing politics in the "in-between the line" space, in which, of course, 
you are completely just outright being a "liar" (for lack of the better 
term).
>
> 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.

I don't 100% know, but I think that is still true and because I am alive 
today and can assess the programming languages of today and see that they 
"don't get it". "big ships turn slowly"-syndrome. Could a 1982 "rant 
thesis" be relevant in 2010! "Hypocrasy!" is outcried!

> It's kind of
> as if he were saying "GC

Ah. Can't have a thread of discussion in a D NG without interjecting GC. 
Sounds like where one bugs out of other religions.

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

No one is going to go back and ponder your tirade about the details of a 
document. Get a grip dude.

>
> "[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.

You are arguing FOR complexity, while he argues for simplicity. See the 
point now?

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

No, no... hang on.. what "exception handling code"? Godwin's law? If you 
start out with the mindset that "exceptions are..." and then conclude "so 
see, exceptions are", you haven't said anything.

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

I didn't remember that as key, but it was a long read. Certainly it is 
too abstract! ;)

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

Not at all. He said: 1.  a programming language exception mechanism does 
not prevent the construction of erroneous programs. 2. a programming 
language exception mechanism curtails the programmer from considering all 
possible consequences of action.

I don't quote him. (2) is what is embodied in the thesis and to single 
out the passage and not realize what was meant, is to be 1. lazy 2. 
unknowledgeable 3. political. Which are you: lazy, unknowledgeable or 
political?

"ain't no strawman"... except for your thoughts on the topic.


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

Hello. It doesn't require such harkening.

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

Now THAT is a strawman! You are a funny guy!

>
> "[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!!!!

Well that must be an "inside secret" then. Show me, then laugh and maybe 
I'll laugh with you.

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

He actually seems to be THINKING about programming rather than just doing 
it as instructed. (Ha ha on me, cuz I wouldn't hire anyone to program for 
me but other than MY way).

>
> Then there's a big convoluted, meandering three-paragraph rant
> involving illegal states but doesn't appear have any obvious point I
> can discern.

You seem to be deeply and emotionally entranced by the document. Like 
those that follow the Greatful Dead?

> My best guess

My bad, people here actually attune to your "best guesses"?

>  is he's trying to say that exceptions are
> part of the specification of the program,

OK, I see you studying under him. You're trying to figure it out (?). (I 
think you have a paradigm though). He has stated many times that no one 
know what an "exception" is. Hello.

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

Obviously YOU don't. (And keep ME out of this please, it's between you 
and him, not me).

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

No. You are playing a semantic game, ignoring the context of the thesis. 
It doesn't make much sense to go on and on in a conversation (or, duh, 
thesis, cuz they'd throw you out of grad school, unless your parents had 
money... or on a (false) date with a woman). Him (in context): I did it 
this way to same effect. You: Wait!, I'll generalize to a level above and 
"win"!. See how you are just a boy and not a man?

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

And the more your snakeoil sales can climb! huh. Dude, he called you 
snakeoil from his grave (I surely hope he went on to do things that make 
him happy).

> I can certainly grant

Oh? How much? I don't talk to anyone who can't grant more than a million. 
THINK before you speak.

> that there are difficulties introduced by exceptions,

THAT is a strawman.

>  but what bugs
> me

That is an indication of paradigm or politics.

> is the implication that exceptions are undesirable purely because

That is the godwin defense.

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

Hello. Your stock price just went to 0.

> "(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.

Then why mention it? His thesis disrupted your whole life and now you 
need to regroup or need help? I can't help you there!
(Good luck with that idiocy).

>
> "(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.
>

He was saying NOTHING about programming and math. Dude: in 1982 there was 
the lingering of math, before that there was Coperincus.

>
> "(iv) Recursive exception handling () is extremely complex."
>
> It's certainly an issue, but I don't know about it being "extremely"
> complex.

You fix it, I may use it. ('may' is the keyword).

> Things like linked exceptions (ie, an exception with a
> "next") certainly help.

I wouldn't know. ;)

>
> "(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."

that't true, obviously. In how many pages of context was this little 
passage? The guy was a STUDENT dude. Get a grip.

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

How do you mean? The thesis asked you for an alternative, eh? Pfft, never 
mind that I ever asked.


Pfft. I never asked that.


It can happen in humanity time, but it can't in computer time. Real-time 
programming should come before any other type of programming instruction.

>
> "(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.

;) You are "too learned".

>
> As for dangers of using exceptions being increased, that may be true
> to a small extent, but I think he's overstating the dangers.

But he presented a thesis. I await yours. (No, no offense, I won't wait).

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

Sure. Market it. Sell it. I dare you.