http://qs321.pair.com?node_id=379243


in reply to Re^4: Automatic stack traces for warns and dies
in thread Automatic stack traces for warns and dies

The second example has a bigger problem, eval {foo} works but foo() on it's own doesn't give a stack trace.
It doesn't?
use Carp qw(confess cluck); BEGIN { *CORE::GLOBAL::warn = \&cluck; *CORE::GLOBAL::die = \&confess; } sub foo { bar() } sub bar { print "in bar\n"; die "badness!" } foo(); __output__ in bar badness! at - line 8 main::bar() called at - line 7 main::foo() called at - line 10
The solution is not a one-liner, it needs to pay attention to $^S which indicates whether we're being eval()ed or not.
But this is dealt with by perl, so even with die and warn overridden the value of $^S will be unaffected.
It should also play well with other die/warn handlers.
And it does
use Carp qw(confess cluck); BEGIN { *CORE::GLOBAL::warn = \&cluck; *CORE::GLOBAL::die = \&confess; } $SIG{__DIE__} = sub { print "I died: @_\n" }; $SIG{__WARN__} = sub { print "watch out: @_\n" }; sub foo { bar() } sub bar { print "in &bar\n"; warn "it's behind you!" } sub baz { qux() } sub qux { print "in &qux\n"; die "ack!" } eval { foo; baz; }; print "The End.\n"; __output__ in &bar watch out: it's behind you! at - line 12 main::bar() called at - line 11 main::foo() called at - line 17 eval {...} called at - line 17 in &qux I died: ack! at - line 15 main::qux() called at - line 14 main::baz() called at - line 17 eval {...} called at - line 17 The End.
My point is, is that overriding die and warn with the corresponding calls from Carp should work fine as they inevitably call die and warn anyhow. The only problems you should run into with these overrides is in existing code where exception handling could very well get muddled, but this shouldn't be a problem if you use subs to localise this behaviour to a given package e.g
{ package Expressive; use Carp qw(confess cluck); use subs qw( die warn ); *die = \&confess; *warn = \&cluck; sub test { warn "warning in ".__PACKAGE__."::test\n"; die "dieing in ".__PACKAGE__."::test\n"; } } print "using Expressive::\n"; eval { Expressive::test }; print $@; print "\nusing main::\n"; eval { warn "warning in ".__PACKAGE__; die "dieing in ".__PACKAGE__; }; print $@; print "\ndone.\n"; __output__ using Expressive:: warning in Expressive::test Expressive::test() called at pmsopw_379099.pl line 18 eval {...} called at pmsopw_379099.pl line 18 dieing in Expressive::test Expressive::test() called at pmsopw_379099.pl line 18 eval {...} called at pmsopw_379099.pl line 18 using main:: warning in main at pmsopw_379099.pl line 23. dieing in main at pmsopw_379099.pl line 24. done.
HTH

_________
broquaint

Replies are listed 'Best First'.
Re^6: Automatic stack traces for warns and dies
by fergal (Chaplain) on Aug 02, 2004 at 12:17 UTC
    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

    perl -Mdiagnostics=-t some_broken_script
    and it'll just work, with no caveats like "be careful with this kind of exception handling" etc.