Perl5 リファレンス

       eval EXPR

       eval BLOCK
               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 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 the wantarray entry elsewhere in this
               document 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.  See the warn entry elsewhere in this
               document 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 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 $@

               Due to the current arguably broken state of
               `__DIE__' hooks, 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 lives here" };
                      print $@ if $@;                # prints "bar lives here"

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

               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

               `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.