Re^4: Where did $@ go?

Replies are listed 'Best First'.
Re^5: Where did $@ go? by Corion (Patriarch) on Mar 21, 2011 at 12:11 UTC
But that doesn't claim anything for the error situation. For example the following will (at least in Perl 5.12, and earlier versions) wipe `$@` even though there is an error: `sub Eater::DESTROY { eval { 1 }; }; my $ok = eval { my $foo = bless {}, 'Eater'; die "Booo!"; 1; }; warn "OK: [$ok]"; warn "\$\@: [$@]";` [download]	[reply] [d/l] [select]
Re^6: Where did $@ go? by John M. Dlugosz (Monsignor) on Mar 21, 2011 at 12:18 UTC
I see. So the implied "and contains the die message or at least a \n" is messed up due to scope localization issues. Maybe that's what's "eating" the string in my case: some kind of destructor. And we should assume such things are happening in a fancy modern class-oriented system. But that doesn't explain why it's still "true". Maybe there is some magic involved and it is remembering that there is an uncaught exception even though the string is gone? So, are the various "fancy" try/catch systems inter-operable? I'm hoping they are all calling the same underlying class and pending-exception state system?	[reply]
Re^5: Where did $@ go? by JavaFan (Canon) on Mar 21, 2011 at 13:31 UTC
"If there was no error, $@ is guaranteed to be a null string." Yeah, but it's useless, because the time frame where $@ is guaranteed to be a null string is less than the width of a semi-colon: `sub DESTROY {$@ = "Hi"} eval {bless []}; say $@; __END__ Hi!` [download] No error, but between the finishing of the `eval`, and the first statement after the `eval`, the return value of `eval` is garbage collected, setting `$@`.	[reply] [d/l] [select]