eval - catch exceptions or compile and run code

- NAME
- SYNOPSIS
- DESCRIPTION

# NAME

eval - catch exceptions or compile and run code

# SYNOPSIS

eval EXPR

eval BLOCK

eval

# DESCRIPTION

In the first form, the return value of EXPR is parsed and executed as if it were a little Perl program. The value of the expression (which is itself determined within scalar context) is first parsed, and if there weren't any errors, executed in the lexical context of the current Perl program, so that any variable settings or subroutine and format definitions remain afterwards. Note that the value is parsed every time the `eval` executes. If EXPR is omitted, evaluates `$_`. This form is typically used to delay parsing and subsequent execution of the text of EXPR until run time.

In the second form, the code within the BLOCK is parsed only once--at the same time the code surrounding the `eval` itself was parsed--and executed within the context of the current Perl program. This form is typically used to trap exceptions more efficiently than the first (see below), while also providing the benefit of checking the code within BLOCK at compile time.

The final semicolon, if any, may be omitted from the value of EXPR or within the BLOCK.

In both forms, the value returned is the value of the last expression evaluated inside the mini-program; a return statement may be also used, just as with subroutines. The expression providing the return value is evaluated in void, scalar, or list context, depending on the context of the `eval` itself. See wantarray in the perlfunc manpage for more on how the evaluation context can be determined.

If there is a syntax error or runtime error, or a `die` statement is executed, an undefined value is returned by `eval`, and `$@` is set to the error message. If there was no error, `$@` is guaranteed to be a null string. Beware that using `eval` neither silences perl from printing warnings to STDERR, nor does it stuff the text of warning messages into `$@`. To do either of those, you have to use the `$SIG{__WARN__}` facility, or turn off warnings inside the BLOCK or EXPR using `no warnings 'all'`. See warn in the perlfunc manpage, the perlvar manpage, the warnings manpage and the perllexwarn manpage.

Note that, because `eval` traps otherwise-fatal errors, it is useful for determining whether a particular feature (such as `socket` or `symlink`) is implemented. It is also Perl's exception trapping mechanism, where the die operator is used to raise exceptions.

If the code to be executed doesn't vary, you may use the eval-BLOCK form to trap run-time errors without incurring the penalty of recompiling each time. The error, if any, is still returned in `$@`. Examples:

        # make divide-by-zero nonfatal
        eval { $answer = $a / $b; }; warn $@ if $@;

        # same thing, but less efficient
        eval '$answer = $a / $b'; warn $@ if $@;

        # a compile-time error
        eval { $answer = };                 # WRONG

        # a run-time error
        eval '$answer =';   # sets $@

Using the `eval{}` form as an exception trap in libraries does have some issues. Due to the current arguably broken state of `__DIE__` hooks, you may wish not to trigger any `__DIE__` hooks that user code may have installed. You can use the `local $SIG{__DIE__}` construct for this purpose, as shown in this example:

        # a very private exception trap for divide-by-zero
        eval { local $SIG{'__DIE__'}; $answer = $a / $b; };
        warn $@ if $@;

This is especially significant, given that `__DIE__` hooks can call `die` again, which has the effect of changing their error messages:

        # __DIE__ hooks may modify error messages
        {
           local $SIG{'__DIE__'} =
                  sub { (my $x = $_[0]) =~ s/foo/bar/g; die $x };
           eval { die "foo lives here" };
           print $@ if $@;                # prints "bar lives here"
        }

Because this promotes action at a distance, this counterintuitive behavior may be fixed in a future release.

With an `eval`, you should be especially careful to remember what's being looked at when:

        eval $x;            # CASE 1
        eval "$x";          # CASE 2

        eval '$x';          # CASE 3
        eval { $x };        # CASE 4

        eval "\$$x++";      # CASE 5
        $$x++;              # CASE 6

Cases 1 and 2 above behave identically: they run the code contained in the variable $x. (Although case 2 has misleading double quotes making the reader wonder what else might be happening (nothing is).) Cases 3 and 4 likewise behave in the same way: they run the code `'$x'`, which does nothing but return the value of $x. (Case 4 is preferred for purely visual reasons, but it also has the advantage of compiling at compile-time instead of at run-time.) Case 5 is a place where normally you would like to use double quotes, except that in this particular situation, you can just use symbolic references instead, as in case 6.

`eval BLOCK` does not count as a loop, so the loop control statements `next`, `last`, or `redo` cannot be used to leave or restart the block.

Note that as a very special case, an `eval ''` executed within the `DB` package doesn't see the usual surrounding lexical scope, but rather the scope of the first non-DB piece of code that called it. You don't normally need to worry about this unless you are writing a Perl debugger.

eval - catch exceptions or compile and run code