GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  PERL::CRITIC::POLICY::ERRORHANDLING::REQUIRECHECKINGRETURNVALUEOFEVAL (3)

.ds Aq ’

NAME

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

CONTENTS

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

CONFIGURATION

This Policy is not configurable except for the standard options.

SEE ALSO

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.

AUTHOR

Elliot Shank <perl@galumph.com>

COPYRIGHT

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.

Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 PERL::CRITIC::POLICY::ERRORHANDLING::REQUIRECHECKINGRETURNVALUEOFEVAL (3) 2016-04-03

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.