in reply to die/warn signal handler best practice questions

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.

  • Comment on Re: die/warn signal handler best practice questions

Replies are listed 'Best First'.
Re^2: die/warn signal handler best practice questions
by bsb (Priest) on Oct 08, 2007 at 23:23 UTC
    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