Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
It doesn't? You had me there for a second, I couldn't understand how I'd messed that up until I realised that you'd swapped foo(). In the original second example foo() threw an object and when confess gets an object it does not produce a stack trace. Just stick a foo() on the end of the original example and you'll see what I mean. But this is dealt with by perl, so even with die and warn overridden the value of $^S will be unaffected. I wasn't talking about changing or not changing $^S. The point is that the die handler should do nothing when $^S is true as this die will be captured by an eval and so adding a stack trace could cause trouble. The only time it should add a stacktrace is when $^S is false. confess does not check $^S, diagnostics.pm does. "die/warn handlers" was probably the wrong phrase, maybe "similar mechanisms" is more correct. Aristotle's code has no effect on the $SIG things. So the question is, "how does it get on with other modules that override *CORE::GLOBAL::die?" and the answer is "not at all". It could be made to but that's not the point, I'm trying to find a module where all that trickiness has been taken care of. Also, using subs to localise to a particular package is not acceptable. The goal is to find something which requires no alteration of the source code whatsoever. diagnostics.pm is about 10 lines away from being exactly what I want. Hopefully you'll be able to do and it'll just work, with no caveats like "be careful with this kind of exception handling" etc. In reply to Re^6: Automatic stack traces for warns and dies
by fergal
|
|