Re: __DIE__ and exception hooks

[Tom Christiansen <tchrist@chthon.perl.com>]

>At the risk of being overly reductionist, is it fair to say that the 
>problem is that authors intend different things at different times by 
>"die"?  That sometimes they want it to mean, "Exit, dammit, and I don't 
>want anything trapping this," sometimes they mean, "This here is an 
>exception which I intend to catch elsewhere," and sometimes they mean, 
>"Exit or be trapped by someone else, I don't care."

>At least, that matches my experience.  I do not see how the current die() 
>can satisfy all these requirements unambiguously and be 
>backwards-compatible - even if you extend the syntax somehow to allow the 
>user to explicitly say which form they mean, there will be all these 
>unextended forms that you don't want to break lying around out there which 
>could mean any one of them.

No, I don't think that's it.  die() always means "raise an exception".
If one intends printf(STDERR) and exit(), one simply employs these.
The issue is one of 

    unless (eval { some_func(); 1 }) {
	if ($@ =~ /woe is me/) {
	    ....
	} 
    } 
    sub some_func { die "woe is me" if rand(25) < 1 }

In logic so simple as this, nobody but *nobody* else had jolly well
better be folding, spindling, or mutilating that exception, for to
do so is an abhorrent notion that tosses all dependability and
determinism out the window and then proceeds to forget just what
window was so abused.  This bug has broken the code of many careful
and professional programmers through unforeseeable interactions
with wicked modules.  Quoth Larry regarding this business:

 1. Any attempt to build a general exception model on it should be
    politely squashed.

 2. Any bug that causes every eval {} to have to be modified should
    be not so politely squashed.

The aspect of this untidy affair that I'm both currently--and
historically--grousing about is principally Larry's second point.
We really *must* fix the extant $SIG{__DIE__} bugs rather than
carrying them forwever forward into future releases to torture our
children with the mistakes of their forefathers.  If creative
individuals wish to address Larry's first point and thereby contemplate
an alternate exception model apart from our current shennanigans
sigDIEabolical, then that, too, would be a good thing, since per
an earlier message of mine this morning, it is hardly apparent to
me at least that the object-based exception stubbage currently
peeping up out from under the covers of Perl has been fully elaborated
into its mature ramifications.

--tom

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---