Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Don't ask to ask, just ask
 
PerlMonks  

die/warn signal handler best practice questions

by bsb (Priest)
on Oct 07, 2007 at 13:08 UTC ( #643270=perlquestion: print w/ replies, xml ) Need Help??
bsb has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to work out how to write well behaved __DIE__ and __WARN__ signal handlers. I've been looking at diagnostics and Devel::SummarizeWarnings, as well as perl's documentation (are there other useful examples?) It seems quite tricky to get right so I'm seeking Perl Wisdom on various aspects.

Firstly, I've seen this magic around:

$Carp::Internal{__PACKAGE__.""}++;
I think it's telling Carp that this package is part of Perl's warning system. There's some documentation in Carp.pm but I'm unclear in which circumstances it should be used (diagnostics uses it, so does Test::NoWarnings).

The $^S variable needs to be checked, the documentation warns of possible changes in __DIE__ handlers from eval { } if you don't.

Another issue is the interraction between handlers. Handlers generally try to play well with others, if there is already a custom __WARN__ or __DIE__ handler installed they are often written to call it (eg. diagnostics again).

Where should you stash the old handler? A lexical (diagnostics), a package var or in the installed closure (Devel::SummarizedWarnings). Another alternative for some circumstances would be making the caller decide. They can replace, local-ize or combine the handlers in either order. Yet another option is some kind of stack.

A related problem is knowing whether you've already install a handler. If handlers are being replaced the you can check the CODE address, but if the handlers are stacked or wrapped (which, as a module writer, you don't control) or if closures are being generated, then it gets more difficult. Is there some way to write a handler that can safely be indirectly wrapped around itself? If you call another handler should you temporarily put it back in %SIG so that it can recognize itself?

If handlers can be installed and later removed, is it work trying to detect misordered/unbalanced calls (ie. only uninstalling if we recognize the top handler).

I noticed it that the diagnostics handler uses goto &$oldwarn to keep the call stack clean for the wrapped handler. Is that good practice in general?

The handler stacking problem seems sufficiently messy that a conservative approach, "don't touch a custom handler", may be best.

There seems to be a risk of accidental recursion, at least I managed to do it. Are there techniques to play safe?

Are there any other tricks or traps?

Brad

Comment on die/warn signal handler best practice questions
Download Code
Re: die/warn signal handler best practice questions
by Somni (Friar) on Oct 07, 2007 at 13:30 UTC

    I don't really want to dredge up all the tricks and traps I've come across dealing with these handlers, but I did want to at least mention the general attitude I came away with.

    These handlers are one of the last bastions of action at a distance in Perl, and they cause no end of trouble. The best approach you can have to them is to avoid them entirely; however, some problems just don't seem to be as easily solved (or maybe solved at all) without them.

    If you're writing a generic module to catch __DIE__ or __WARN__ that anyone can use, and that will interact well with other code trying to do the same thing, good luck. You'll need it. However, if you're trying to design a framework that will be largely consistent throughout it becomes a bit easier. I wrote a small web framework a long time back that relied on it. I wouldn't recommend it.

    My best recommendation to avoid __DIE__ handlers in particular is to make heavy use of block eval and die. __DIE__ is essentially a try/catch design turned inside out; turning it back right-side in might be a far better approach.

      I am trying to write a generic warn/die wrapper for general use (Devel::file). Worse still, I'd like people to be able to enable it in their environment and forget about it.

      Your comments suggest that keeping things simple, safe and conservative might be the best approach. Thanks

Re: die/warn signal handler best practice questions
by TOD (Friar) on Oct 08, 2007 at 03:50 UTC
    in general: don't trust people telling you to never do this or that. ;)
    second, i think you overestimate the complexity of that handler problem. as you can see from e.g. perldoc -f local, it's very easy to let every process take control over its own reactions on __DIE__ and __WARN__ signals. and if you strictly distiguish between the process and the modules it loads it becomes fairly clear (to me), that a module should simply die, whilst the process redirects that signal to maybe a logging thread or any other appropriate stuff.
    --------------------------------
    masses are the opiate for religion.
      What you say is true for applications, but I'm trying to write a module that installs die/warn handlers.

      I could just return the handler to install and let the user do the local($SIG{..}) in the correct scope... That's an awkward interface, but might but useful in some circumstances.

      Thanks for your comments

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://643270]
Approved by moritz
Front-paged by moritz
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2014-04-20 20:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (487 votes), past polls