Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
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:

I think it's telling Carp that this package is part of Perl's warning system. There's some documentation in 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?


In reply to die/warn signal handler best practice questions by bsb

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2023-03-31 18:27 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (76 votes). Check out past polls.