Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval - You can't depend upon the value of C<$@>/C<$EVAL_ERROR> to tell whether an C<eval> failed. |
Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval - You can't depend upon the value of $@
/$EVAL_ERROR
to tell whether an eval
failed.
This Policy is part of the core Perl::Critic distribution.
A common idiom in perl for dealing with possible errors is to use
eval
followed by a check of $@
/$EVAL_ERROR
:
eval { ... }; if ($EVAL_ERROR) { ... }
There's a problem with this: the value of $EVAL_ERROR
can change
between the end of the eval
and the if
statement. The issue is
object destructors:
package Foo;
...
sub DESTROY { ... eval { ... }; ... }
package main;
eval { my $foo = Foo->new(); ... }; if ($EVAL_ERROR) { ... }
Assuming there are no other references to $foo
created, when the
eval
block in main
is exited, Foo::DESTROY()
will be invoked,
regardless of whether the eval
finished normally or not. If the
eval
in main
fails, but the eval
in Foo::DESTROY()
succeeds, then $EVAL_ERROR
will be empty by the time that the if
is executed. Additional issues arise if you depend upon the exact
contents of $EVAL_ERROR
and both eval
s fail, because the
messages from both will be concatenated.
Even if there isn't an eval
directly in the DESTROY()
method
code, it may invoke code that does use eval
or otherwise affects
$EVAL_ERROR
.
The solution is to ensure that, upon normal exit, an eval
returns a
true value and to test that value:
# Constructors are no problem. my $object = eval { Class->new() };
# To cover the possiblity that an operation may correctly return a # false value, end the block with "1": if ( eval { something(); 1 } ) { ... }
eval { ... 1; } or do { # Error handling here };
Unfortunately, you can't use the defined
function to test the
result; eval
returns an empty string on failure.
Various modules have been written to take some of the pain out of
properly localizing and checking $@
/$EVAL_ERROR
. For example:
use Try::Tiny; try { ... } catch { # Error handling here; # The exception is in $_/$ARG, not $@/$EVAL_ERROR. }; # Note semicolon.
``But we don't use DESTROY()
anywhere in our code!'' you say. That may
be the case, but do any of the third-party modules you use have them?
What about any you may use in the future or updated versions of the
ones you already use?
This Policy is not configurable except for the standard options.
See thread on perl5-porters starting here: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-06/msg00537.html.
For a nice, easy, non-magical way of properly handling exceptions, see Try::Tiny.
Elliot Shank <perl@galumph.com>
Copyright (c) 2008-2011 Elliot Shank.
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of this license can be found in the LICENSE file included with this module.
Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval - You can't depend upon the value of C<$@>/C<$EVAL_ERROR> to tell whether an C<eval> failed. |