Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

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

by ides (Deacon)
on Dec 26, 2007 at 16:44 UTC ( #659063=note: print w/replies, xml ) Need Help??

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

What do you expect to happen? You are localizing the eval_error variable, not using it for anything, and not even using it in an eval.

Frank Wiles <>

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

Replies are listed 'Best First'.
Re^2: Unexpected result after localizing eval_error variable "$@" within "BEGIN" block
by Errto (Vicar) on Dec 26, 2007 at 16:58 UTC

    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.

      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
Node Status?
node history
Node Type: note [id://659063]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2017-09-25 02:39 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (275 votes). Check out past polls.