eval BLOCK
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. If
EXPR is omitted, evaluates $_
. The final semicolon, if any, may be omitted from the expression. 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. See warn
and the perlvar 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 non-fatal eval { $answer = $a / $b; }; warn $@ if $@;
# same thing, but less efficient eval '$answer = $a / $b'; warn $@ if $@;
# a compile-time error eval { $answer = };
# a run-time error eval '$answer ='; # sets $@
When using the eval{} form as an exception trap in libraries, 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 foofs here" }; print $@ if $@; # prints "bar barfs here" }
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 that particular situation, you
can just use symbolic references instead, as in case 6.