The essence of your complaint is correct. eval { } does not know anything about fork. After you fork, both processes continue.
Basically this comes down to people not being thorough enough when they're spawning external programs, and/or not passing through error return values from child processes as exceptions correctly.
The following constructs should be safe, and libraries using them should raise errors trappable with eval { }:
system("foo") == 0 or die "foo failed; rc=$?"; defined(my $pid = open FOO, "command|") or die "exec failed; $!"; # ... do something with FOO ... close FOO; ($? == 0) or die "sub-process `command' failed; rc=$?";
In general, detecting all nature of errors is outside of the scope of eval { }. As far as Perl is concerned, MIME::Lite successfully returned without noticing its sub-process failed, so there was no trappable error.
$h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/." ."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";
In reply to Re: forked die() in eval block has counterintuitive behavior?
by mugwumpjism
in thread forked die() in eval block has counterintuitive behavior?
by rlucas
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |