__DIE__ and exception hooks

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

This message is being forwarded to you under explicit permission
from its original author.  

Given the observed empirical evidence that of late, it seems as
though everyone and his banker is, like a moth to a lamp, drawn
toward rewriting, re-inventing, or intercepting Perl's exception-handling
mechanism, it appears clear to this writer that a modicum of earnest
yet civil discussion is merited in pursuit of exploring how one
might go about implementing mechanisms of this nature, particularly
with respect to how one might effect a solution that does not
inadvertently or even with premeditated intent trample upon unrelated
code so as to require that said code be summarily rewritten in a
paranoiacally defensive manner to insulate itself from any external
party's malicious tampering with its own private exception handlers
which, in consequence, would cause perfectly innocent code to
spontaneously and mysteriously break.

Do please include Dr. Dintelman in your *kind* replies--and, of
course, similarly omit him should you be unable to resist the
temptation to respond inflammatorily.

thanks you,

--tom

[The following message was slightly reformatted to better accord with
 expected norms regarding quoting conventions.]

------- Forwarded Message

From: "Dintelmann, Peter" <Peter.Dintelmann@dresdner-bank.com>
To: "'Tom Christiansen'" <tchrist@chthon.perl.com>
Subject: AW: signal handler 
Date: Tue, 18 Jan 2000 14:49:17 +0100

Hi Tom,

thanks for the quick reply.

>Well, if it's just hints you're looking for :-), then here's one:

>   % cd /usr/local/src/perl5.005_63/pod
>   % egrep -l '__(WARN|DIE)__' *.pod

well, I've done that b4 of course ;-)

>You'll find that due to a bug, "die" handlers get triggered on any
>die, rather than just on an untrapped one.  

I thought it was a feature *smile*.

>The last word from Larry on this gross infelicity was:
>
>    The original intent of __DIE__ was only to allow you to substitute
>    one kind of death for another on an application-wide basis
>    without respect to whether you were in an eval or not.  As a
>    global backstop, it should not be used any more lightly (or any
>    more heavily :-) than class UNIVERSAL.  Any attempt to build a
>    general exception model on it should be politely squashed.  Any
>    bug that causes every eval {} to have to be modified should be
>    not so politely squashed.

Taking that into account I have to rethink some things...  Actually
I am developing a package for writing logfiles (supporting different
media like plain files, email etc.)  Now when someone (i.e. myself ;-) 
is using this code there should not arise the need for rewriting
code.  Thus in standard 'die' cases like

    open( FH_IN, $file ) || die $!;

a message should find its way (automat/gically) in all currently
open log files (the same for 'warn') and they should be closed (for
an smtp based log 'closing' means in particular sending out the
mail).

To this end I wanted to use $SIG{__DIE__} and ...__WARN__.

Now taking Larry's opinion into account what do you recommend???
(Should I rather use the END block instead? But how do I know that
a 'die'/'warn' happened before?)

The original question I was interested in was: Suppose you have a
complex hierarchy of 'use'ing packages and each package comes along
with its own handler(s) what is the order of their execution?  Does
__DIE__ travel up (and how?) the 'use'-hierarchy in the sense that
first the handler of the package the die arose in is invoked and
that the last handler invoked is the one from the 'main' package?

Thanks in advance for any help.

Regards,

        Peter

- --
Dr. Peter Dintelmann
Dresdner Bank AG
KS OI KB MIS
Windmuehlstr. 14/2E
D-60301 Frankfurt
Germany

Tel.: +49-(0)69-263-19722
Email: Peter.Dintelmann@dresdner-bank.com


------- End of Forwarded Message

---

Follow-Ups from:

Peter Scott <Peter@PSDT.com>

---

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

---