eval in all its forms is used to execute a little Perl program, trapping any errors encountered so they don't crash the calling program.

Plain eval with no argument is just eval EXPR, where the expression is understood to be contained in $_. Thus there are only two real eval forms; the one with an EXPR is often called "string eval". In a string eval, the value of the expression (which is itself determined within scalar context) is first parsed, and if there were no errors, executed as a block within the lexical context of the current Perl program. This form is typically used to delay parsing and subsequent execution of the text of EXPR until run time. Note that the value is parsed every time the eval executes.

The other form is called "block eval". It is less general than string eval, but 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, while also providing the benefit of checking the code within BLOCK at compile time. BLOCK is parsed and compiled just once. Since errors are trapped, it often is used to check if a given feature is available.

In both forms, the value returned is the value of the last expression evaluated inside the mini-program; a return statement may also be 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 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, eval returns undef in scalar context, or an empty list in list context, and $@ is set to the error message. (Prior to 5.16, a bug caused undef to be returned in list context for syntax errors, but not for runtime errors.) If there was no error, $@ is set to the empty string. A control flow operator like last or goto can bypass the setting of $@. 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, perlvar, and warnings.

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.

Before Perl 5.14, the assignment to $@ occurred before restoration of localized variables, which means that for your code to run on older versions, a temporary is required if you want to mask some, but not all errors:

# alter $@ on nefarious repugnancy only
{
   my $e;
   {
     local $@; # protect existing $@
     eval { test_repugnancy() };
     # $@ =~ /nefarious/ and die $@; # Perl 5.14 and higher only
     $@ =~ /nefarious/ and $e = $@;
   }
   die $e if defined $e
}

There are some different considerations for each form:

#String eval

Since the return value of EXPR is executed as a block within the lexical context of the current Perl program, any outer lexical variables are visible to it, and any package variable settings or subroutine and format definitions remain afterwards.

#Under the "unicode_eval" feature

If this feature is enabled (which is the default under a use 5.16 or higher declaration), EXPR is considered to be in the same encoding as the surrounding program. Thus if use utf8 is in effect, the string will be treated as being UTF-8 encoded. Otherwise, the string is considered to be a sequence of independent bytes. Bytes that correspond to ASCII-range code points will have their normal meanings for operators in the string. The treatment of the other bytes depends on if the 'unicode_strings" feature is in effect.

In a plain eval without an EXPR argument, being in use utf8 or not is irrelevant; the UTF-8ness of $_ itself determines the behavior.

Any use utf8 or no utf8 declarations within the string have no effect, and source filters are forbidden. (unicode_strings, however, can appear within the string.) See also the evalbytes operator, which works properly with source filters.

Variables defined outside the eval and used inside it retain their original UTF-8ness. Everything inside the string follows the normal rules for a Perl program with the given state of use utf8.

#Outside the "unicode_eval" feature

In this case, the behavior is problematic and is not so easily described. Here are two bugs that cannot easily be fixed without breaking existing programs:

• It can lose track of whether something should be encoded as UTF-8 or not.

• Source filters activated within eval leak out into whichever file scope is currently being compiled. To give an example with the CPAN module Semi::Semicolons:

  BEGIN { eval "use Semi::Semicolons; # not filtered" }
  # filtered here!

  evalbytes fixes that to work the way one would expect:

  use feature "evalbytes";
  BEGIN { evalbytes "use Semi::Semicolons; # filtered" }
  # not filtered

Problems can arise if the string expands a scalar containing a floating point number. That scalar can expand to letters, such as "NaN" or "Infinity"; or, within the scope of a