in reply to Re: seeking eval failures
in thread seeking eval failures

I think you're missing what he's saying. Your code works. However, consider *why* it's working. Suppose I have the following code:

#!/usr/bin/perl
use Data::Dumper;
my $a = eval {
eval {
die;
}
};
print Dumper($a,$@);
__DATA__
output:
$VAR1 = undef;
$VAR2 = '';

[download]

Look at that. It returns undef and $@ is an empty string just as bronto was looking for. This, however, is because the eval inside did its job. It stopped runtime errors from propogating upwards and returned undef. The outer eval didn't notice a thing and as such happily set $@ to '' and returned the last thing in the block, which was the undef from the eval. As far as what the OP is looking for, I'm with Abigail-II on this one. I don't see any way of getting $@ empty on a bad eval.

antirice    
The first rule of Perl club is - use Perl
The ith rule of Perl club is - follow rule i - 1 for i > 1

Replies are listed 'Best First'.
Re: Re: Re: seeking eval failures
by CombatSquirrel (Hermit) on Aug 18, 2003 at 09:44 UTC
    Yes, sorry. Seems as if you guys were right. But why exactly does the eval have to fail? Where could you detect the difference? I mean, after all the return value of the outer eval is the same as the one of the inner eval and $@ is empty, as specified.
[reply]
[d/l]
      You are responsible for propagating $@ to the outer most eval. 
      eval {
   die "borg";
};
warn "whoops $@" if $@;

eval {
    eval {
        die "borg";
    };
    die $@ if $@; # essentially "rethrow" an "exception" if it occured
};

warn "whoops $@" if $@;
__END__
whoops borg at - line 2.
whoops borg at - line 8.

      [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom