FAQ
In perl56delta.pod it says:

"When code in a destructor threw an exception, it went unnoticed
in earlier versions of Perl, unless someone happened to be
looking in $@ just after the point the destructor happened to
run. Such failures are now visible as warnings when warnings are
enabled."

However, it seems that this is only true if the exception thrown is a
string. If the destructor throws an object, even one with overloaded
stringification, then the error still goes unreported.

I can work around it by eval'ing the code within the destructor (being
careful to localize $@), catching the exception object and throwing the
error again after explicitly stringifying it, but I wondered if the
current behaviour is intentional or a bug? If it is by design then it at
least ought to be documented somewhere. (I didn't see any mention in the
current manpages of it being deliberate.)

The following code shows the problem: it does not print anything. If it
called die("BANG!\n") in the destructor then it would have printed that
error as a warning "(in cleanup) ...".

use strict;
use warnings;
package MyError;
use overload '""' => sub { "BANG!\n" };
sub new { return bless {}, shift; }
package Foo;
sub new { return bless {}, shift; }
sub DESTROY { die MyError->new(); }
package main;
my $foo = Foo->new();

Search Discussions

  • Zefram at May 13, 2011 at 9:17 am

    Steve Hay wrote:
    However, it seems that this is only true if the exception thrown is a
    string. If the destructor throws an object, even one with overloaded
    stringification, then the error still goes unreported.
    That's changing in 5.14.

    -zefram

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMay 13, '11 at 8:50a
activeMay 13, '11 at 9:17a
posts2
users2
websiteperl.org

2 users in discussion

Zefram: 1 post Steve Hay: 1 post

People

Translate

site design / logo © 2022 Grokbase