---
name: "Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval"
section: "3pm"
platform: "linux"
package: "perl-perl-critic"
version: "1.156-3"
release: "Arch Linux 2026-11-01"
platforms: ["linux"]
url: "https://new.carta.tech/Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval"
---

# Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval(3pm)

You can't depend upon the value of "$@"/"$EVAL\_ERROR" to tell whether an "eval" failed.

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

## SEE ALSO

For a nice, easy, non-magical way of properly handling exceptions, see Try::Tiny.

## AUTHOR

Elliot Shank `"<perl@galumph.com>"`

## COPYRIGHT

Copyright (c) 2008-2023 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.