eval EXPR
eval BLOCK
[...]
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.
[...]
In both forms, the value returned is the value of the last
expression evaluated inside the mini-program; a return state-
ment may be also used, just as with subroutines. The expres-
sion 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" state-
ment 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" nei-
ther 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, warnings and perllexwarn.
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.
</pr>
$\=~s;s*.*;q^|D9JYJ^^qq^\//\\\///^;ex;print
In reply to Re: XML::Twig error handling
by Skeeve
in thread XML::Twig error handling
by ramya2005
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |