Well, it does make a difference. Without that line, this code throws an error, as expected. With that line, it doesn't. Seems like a potential bug.
The behavior is not unique to invalid subroutine calls. More or less any error under the (F) category in perldiag seems to produce this behavior - not all though, for example it still dies if I put in a division by zero. Though even then, it just prints the dying message - no mention of it having anything to do with BEGIN (unlike the other errors).
Update: above paragraph is slightly wrong. The difference has to do with whether the error can be caught at compile time or not. Compile time errors still die. But runtime errors get ignored in this construct.
Update 2: While re-reading perlmod I failed to notice the line chromatic quoted. So that at least explains why $@ and BEGIN have anything to do with each other at all. But I agree with demerphq; localizing $@ inside eval'd code shouldn't silently cause subsequent errors from that code not to be reported in the enclosing code.
| [reply] |
#!C:/perl/bin
use warnings;
use strict;
BEGIN {
local $@;
# call_undefined_subroutine_or_another_error("argument");
}
print "blabla\n";
from perldoc perlvar
Error Indicators
The variables $@, $!, $^E, and $? contain information about different
types of error conditions that may appear during execution of a Perl
program. The variables are shown ordered by the "distance" between the
subsystem which reported the error and the Perl process. They correspond
to errors detected by the Perl interpreter, C library, operating system,
or an external program, respectively.
To illustrate the differences between these variables, consider the
following Perl expression, which uses a single-quoted string:
eval q{
open my $pipe, "/cdrom/install |" or die $!;
my @res = <$pipe>;
close $pipe or die "bad pipe: $?, $!";
};
After execution of this statement all 4 variables may have been set.
$@ is set if the string to be "eval"-ed did not compile (this may happen
if "open" or "close" were imported with bad prototypes), or if Perl code
executed during evaluation die()d . In these cases the value of $@ is
the compile error, or the argument to "die" (which will interpolate $!
and $?). (See also Fatal, though.)
| [reply]
[d/l] |
The point is that even if you uncomment that line, or replace it with some other error-causing statement, you get no error on the versions of Perl I tested, whereas there should be an error as far as I can tell.
Update: Sorry I'm being unclear. What I meant above was the local $@ line; that is what's causing the strange behavior.
| [reply]
[d/l] |