develooper Front page | perl.perl5.porters | Postings from June 2008

Re: Why $@ makes me cry (was Re: Generic system() replacements)

Thread Previous | Thread Next
Mark Mielke
June 24, 2008 14:35
Re: Why $@ makes me cry (was Re: Generic system() replacements)
Message ID:
Abigail wrote:
> Eh, I know I shouldn't have done this, but I have written code that could
> die inside a DESTROY, with an eval to capture this exception. That code
> would fail if $@ is saved before a DESTROY and then restored.
> Now, I don't really care about this specific piece of code (I doubt it's
> still running), but there might be some other code out there that relies
> on this. That's not to say I would oppose such a change, IMO, the benefits
> outweight the breakage of code written by a handful of freaks, but in general
> we do care about backwards compat issues.

I think the link between $@ being a global and eval{} being recursive is 
the real problem. What about some compromise whereby $@ is saved before, 
and only restored if DESTROY completes successfully without an exception?

If an exception occurs within DESTROY - I think it should recurse up the 
stack as an exception. But if DESTROY doesn't fail, I don't think any 
adjustment it does to $@ should take effect in the caller?


P.S. Been staying out of this thread for a while - but I too have been 
bit by this eval{} problem in production code, and I do local($@, $?, 
$!) in the DESTROY block. I've actually been hit by all three *sigh*. 
The $? was REALLY annoying because the DESTROY indirectly called a 
sub-command under some conditions, and the $? would be intercepted and 
translated to 255. No matter what I did "exit 0;" or "exit 1;", Perl 
would still exit with 255. WTF? Finally I traced it to DESTROY and $?. 

Mark Mielke <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About