NAME

Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval - You can't depend upon the value of "$@"/"$EVAL_ERROR" to tell whether an "eval" failed.

AFFILIATION

This Policy is part of the core Perl::Critic distribution.

DESCRIPTION

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 possibility 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?

CONFIGURATION

This Policy is not configurable except for the standard options.

AUTHOR

Elliot Shank "<perl@galumph.com>"

COPYRIGHT