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

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

Thread Previous | Thread Next
From:
Graham Barr
Date:
June 25, 2008 10:04
Subject:
Re: Why $@ makes me cry (was Re: Generic system() replacements)
Message ID:
75490A3B-D61E-4AC4-8BDC-1732691A15D0@pobox.com
On Jun 24, 2008, at 5:01 PM, Jan Dubois wrote:
> On Tue, 24 Jun 2008, Abigail wrote:
>>
>> On Sat, Jun 21, 2008 at 12:25:53PM +1000, Paul Fenwick wrote:
>>>
>>> However I believe there may be some merit in saving $@ before a  
>>> DESTROY
>>> is called, and restoring it afterwards.  That allows destruction  
>>> to occur
>>> as it always has, but prevents said destruction from clobbering  
>>> $@.  I
>>> imagine trying to capture a $@ from object destruction that's  
>>> essentially
>>> happening "between the lines" is going to be a rather rare  
>>> occurrence
>>> indeed.
>>
>>
>> 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.
>
> Can you post some code example that does this? A call to die($msg)
> inside DESTROY does not raise an exception, it simply does the
> equivalent of
>
>    $@ .= "\t(in cleanup) $msg";

$@ is not always a string. The core always creates strings itself, but  
users can call die with an object.

So the above is OK if $@ is already a string, but if it is an object  
then the object should decide how to deal with it.

For example, if $@ is an object and you call die; with no arguments,  
perl calls $@->PROPAGATE; A similar API should be designed to handle  
out of band errors.

Graham.


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About