Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
Perl::Perl::Critic::PoUser:ContributediPerlRDocumentationgReturnValueOfEval(3)

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

perl vPerl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval(3)

NAME | AFFILIATION | DESCRIPTION | CONFIGURATION | SEE ALSO | AUTHOR | COPYRIGHT

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval&sektion=3&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help