Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^2: Unexpected result after localizing eval_error variable "$@" within "BEGIN" block

by Errto (Vicar)
on Dec 26, 2007 at 16:58 UTC ( #659071=note: print w/replies, xml ) Need Help??

in reply to Re: Unexpected result after localizing eval_error variable "$@" within "BEGIN" block
in thread Unexpected result after localizing eval_error variable "$@" within "BEGIN" block

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.

  • Comment on Re^2: Unexpected result after localizing eval_error variable "$@" within "BEGIN" block

Replies are listed 'Best First'.
Re^3: Unexpected result after localizing eval_error variable "$@" within "BEGIN" block
by ww (Archbishop) on Dec 26, 2007 at 17:10 UTC

    Is line 7 (now commented out) what you referred to?

    no error here on:
    #!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.)

      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.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://659071]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (2)
As of 2023-12-02 06:00 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (13 votes). Check out past polls.