Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

perl::critic::policy::subroutines::prohibitexplicitreturnundef(3pm) [debian man page]

Perl::Critic::Policy::Subroutines::ProhibitExplicitReturUsereContributed Perl DPerl::Critic::Policy::Subroutines::ProhibitExplicitReturnUndef(3pm)

NAME

       Perl::Critic::Policy::Subroutines::ProhibitExplicitReturnUndef - Return failure with bare "return" instead of "return undef".

AFFILIATION

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

DESCRIPTION

       Returning "undef" upon failure from a subroutine is pretty common.  But if the subroutine is called in list context, an explicit "return
       undef;" statement will return a one-element list containing "(undef)".  Now if that list is subsequently put in a boolean context to test
       for failure, then it evaluates to true.	But you probably wanted it to be false.

	 sub read_file {
	     my $file = shift;
	     -f $file || return undef;	#file doesn't exist!

	     #Continue reading file...
	 }

	 #and later...

	 if ( my @data = read_file($filename) ){

	     # if $filename doesn't exist,
	     # @data will be (undef),
	     # but I'll still be in here!

	     process(@data);
	 }
	 else{

	     # This is my error handling code.
	     # I probably want to be in here
	     # if $filname doesn't exist.

	     die "$filename not found";
	 }

       The solution is to just use a bare "return" statement whenever you want to return failure.  In list context, Perl will then give you an
       empty list (which is false), and "undef" in scalar context (which is also false).

	 sub read_file {
	     my $file = shift;
	     -f $file || return;  #DWIM!

	     #Continue reading file...
	 }

CONFIGURATION

       This Policy is not configurable except for the standard options.

NOTES

       You can fool this policy pretty easily by hiding "undef" in a boolean expression.  But don't bother trying.  In fact, using return values
       to indicate failure is pretty poor technique anyway.  Consider using "die" or "croak" with "eval", or the Error module for a much more
       robust exception-handling model.  Conway has a real nice discussion on error handling in chapter 13 of PBP.

SEE ALSO

       There's a discussion of the appropriateness of this policy at <http://perlmonks.org/index.pl?node_id=741847>.

AUTHOR

       Jeffrey Ryan Thalhammer <jeff@imaginative-software.com>

COPYRIGHT

       Copyright (c) 2005-2011 Imaginative Software Systems.  All rights reserved.

       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 v5.14.2							    2012-06-07 Perl::Critic::Policy::Subroutines::ProhibitExplicitReturnUndef(3pm)

Check Out this Related Man Page

Perl::Critic::Policy::BuiltinFunctions::ProhibitStringyEUser3Contributed Perl DocumePerl::Critic::Policy::BuiltinFunctions::ProhibitStringyEval(3)

NAME

       Perl::Critic::Policy::BuiltinFunctions::ProhibitStringyEval - Write "eval { my $foo; bar($foo) }" instead of "eval "my $foo; bar($foo);"".

AFFILIATION

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

DESCRIPTION

       The string form of "eval" is recompiled every time it is executed, whereas the block form is only compiled once.  Also, the string form
       doesn't give compile-time warnings.

	   eval "print $foo";	     # not ok
	   eval {print $foo};	     # ok

CONFIGURATION

       There is an "allow_includes" boolean option for this Policy.  If set, then strings that look like they only include a single "use" or
       "require" statement (with the possible following statement that consists of a single number) are allowed.  With this option set, the
       following are flagged as indicated:

	   eval 'use Foo';	       # ok
	   eval 'require Foo';	       # ok
	   eval "use $thingy;";        # ok
	   eval "require $thingy;";    # ok
	   eval "use $thingy; 1;";     # ok
	   eval "require $thingy; 1;"; # ok

	   eval 'use Foo; blah;';      # still not ok
	   eval 'require Foo; 2; 1;';  # still not ok
	   eval 'use $thingy;';        # still not ok
	   eval 'no Foo';	       # still not ok

       If you don't understand why the number is allowed, see Perl::Critic::Policy::ErrorHandling::RequireCheckingReturnValueOfEval.

       This option inspired by Ricardo SIGNES' Perl::Critic::Policy::Lax::ProhibitStringyEval::ExceptForRequire.

SEE ALSO

       Perl::Critic::Policy::ControlStrucutres::RequireBlockGrep

       Perl::Critic::Policy::ControlStrucutres::RequireBlockMap

AUTHOR

       Jeffrey Ryan Thalhammer <jeff@imaginative-software.com>

COPYRIGHT

       Copyright (c) 2005-2011 Imaginative Software Systems.  All rights reserved.

       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 v5.16.3							    2014-06-09	    Perl::Critic::Policy::BuiltinFunctions::ProhibitStringyEval(3)
Man Page