Re: eval failure does not set $@

eval sets "$@" with the output of what you'd normally see perl output if there were errors compiling your program.

perl normally wouldn't display runtime errors if a subroutine doesn't do what it is supposed to do.

eval won't either.

If the routines you are running return a status, then you want to catch that status coming back from eval:

my $status = eval "3+4";
[download]

$status should be '7'. Only if the code you are executing "dies" or throws a warning, in the perl sense, would eval return something in $@.

Does that help?

Comment on Re: eval failure does not set $@ Download Code

Replies are listed 'Best First'.
Re^2: eval failure does not set $@ by haukex (Archbishop) on Jun 06, 2018 at 20:51 UTC
Only if the code you are executing "dies" or throws a warning, in the perl sense, would eval return something in $@. But as I wrote, there are cases where the code in the eval can die, and $@ doesn't get set (Update: or to be more specific, gets clobbered so that it's no longer available after the `eval`). A simple demo of this bug: `use warnings; use strict; sub Foo::DESTROY { eval {} } eval { for (bless {}, "Foo") { print "Hello"; die "KABOOM"; } }; print "<$@>\n"; # Where's the kaboom? There was supposed # to be an earth-shattering kaboom!` [download] Even on Perl 5.26, this only prints "`Hello<>`". That's why the `eval { ...; 1 } or do { ... };` pattern is better - choroba showed how that pattern still works even in the presence of a similar bug on Perls <5.14 here. If the routines you are running return a status, then you want to catch that status coming back from eval I would suggest writing it this way, where of course `3+4` is a stand-in for something more complex (and it may also be a false value): `my $status; eval '$status = 3+4; 1' or warn $@\|\|"unknown error";` [download]	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: eval failure does not set $@
by haukex (Archbishop) on Jun 06, 2018 at 20:51 UTC

Only if the code you are executing "dies" or throws a warning, in the perl sense, would eval return something in $@.

But as I wrote, there are cases where the code in the eval can die, and $@ doesn't get set (Update: or to be more specific, gets clobbered so that it's no longer available after the eval). A simple demo of this bug:

use warnings;
use strict;

sub Foo::DESTROY { eval {} }

eval {
    for (bless {}, "Foo") {
        print "Hello";
        die "KABOOM";
    }
};
print "<$@>\n";  # Where's the kaboom? There was supposed
                 # to be an earth-shattering kaboom!
[download]

Even on Perl 5.26, this only prints "Hello<>". That's why the eval { ...; 1 } or do { ... }; pattern is better - choroba showed how that pattern still works even in the presence of a similar bug on Perls <5.14 here.

If the routines you are running return a status, then you want to catch that status coming back from eval

I would suggest writing it this way, where of course 3+4 is a stand-in for something more complex (and it may also be a false value):

my $status;
eval '$status = 3+4; 1' or warn $@||"unknown error";
[download]

[reply]
[d/l]
[select]