Well, they could have written that as

my $res = eval {
 something(...);
};
die $@ if $@;
do_something_more(...);
[download]

But! compare

use Carp;
$SIG{__DIE__} = \&Carp::confess;
my $res = foo();
print "ok\n";

sub foo {
    local $SIG{__DIE__};
    die "BANG!";
}
__END__
BANG! at - line 8.
[download]

and

use Carp;
$SIG{__DIE__} = \&Carp::confess;
my $res = eval { foo() };
die $@ if $@;
print "ok\n";

sub foo {
    local $SIG{__DIE__};
    die "BANG!";
}
__END__
BANG! at - line 9.
 at - line 4
[download]

I guess it's not cargo-culting... the eval BLOCK and subsequent die provides an additional frame for Carp to consider.

Well.. Actually I don't think you have to play tricks with $SIG{__DIE__} to obtain a different result. calling confess() within the something(...) would show that additional frame as well.

I don't see any reason to want that though. What's that additional frame good for? Apart from maybe causing you to look at that part of the code and thus wasting time. I think the additional frame is at best confusing.

Jenda


Support Denmark! Defend the free world!

What's that additional frame good for?

something() might be in some other module which you don't control. That technique allows you to delay the exit until the very line where you choose to die. An that's precisely what eval BLOCK is all about - delay the die, to mask it or die elsewhere.

That construction has crept into my code a few times and it's been because I was planning on doing something with the exception but ended up just letting it lie because I got sidetracked or went off a'testing from the outside and stopped looking at the code directly. It's easy to forget to do anything about it when it's behaving the same way, mostly, as if it weren't there.

Actually the eval { ... }; if ($@) { ... } pattern is dangerous. Consider this example:

use 5.010;
use strict;
use warnings;

sub DESTROY { eval { "no error here" } }

eval {
    my $x = bless {};
    die "an error here";
};

say $@ ? "ERROR" : "no error caught";
[download]

This reports no error caught, because $x goes out of scope, the DESTROY method is called, which in turn executes an eval that rests $@. Hooray for global variables. (This is one of the reasons that Perl 6 has context variables instead).

A safer meme is

my $success = eval { ...; 1 }
[download]

So back to the question, what's the difference? It's that in the case with eval and if the code doesn't work as expected if some DESTROY method forgot to localize $@.

Actually, eval without diagnostics after the call and without localizing $@ is what's dangerous here, not the pattern itself. And that doesn't apply to DESTROY only, although not with such catastrophic consequences. Like trampling on $_. Yes, "hooray for global variables"... ;-)

{
    local $SIG{__DIE__};
    local $@ = "";
                                                                   
    eval {
        local $SIG{ALRM} = sub { die("alarm\n") };

        alarm(3);
        chomp($input = <STDIN>); # potentially long operation
        alarm(0);

        1;
    } or do {
        die($@) unless $@ eq "alarm\n";
                                                                   
        # timed out
        warn("No answer for three seconds.\n");
        $input = "";
    }
}
[download]

Note that anything that happens to alter $SIG{__DIE__} would break that since the exception string wouldn't be "alarm\n" anymore.

I've done that myself numerous times when adding a use Carp::Always; for debugging purposes, thereby accidentally the whole test run.

If you want to be extra super safe, you should do local $SIG{__DIE__}; in the block as well.

/J