EXP00-PL. Do not return undef

Perl expressions can be interpreted in either scalar or list context, depending on the syntactic placement of the expression. Many functions are designed to return only a scalar, or only a list. Many builtin functions can be called in both contexts, and they may return differing values for each. Furthermore, any function may specify exactly what to return in each context.

Returning the value undef is a common convention for a function to indicate it has no return value. This is often used to indicate that an error occured, or that a function was not able to successfully complete an operation. When used as the conditional in a conditional expression (such as in an if statement), undef evaluates to false. Therefore a function that is only ever evaluated in scalar context may safely return undef to indicate failure.

However, in list context, things are slightly more complicated. An empty list when evaluated in a boolean condition evaluates to false. But the value undef when evaluated in list context evaluates to true. This is because it is converted to a list with the singleton value undef. Therefore, a function should not return undef if it might ever be invoked in list context.

Noncompliant Code Example

This noncompliant code example opens the /etc/shadow file to process the users and encrypted passwords on a POSIX system. Since the /etc/shadow file is conventionally only readable by the root user, this program must gracefully abort if it is not allowed to read this file.

sub read_users {
  open( my $filehandle, "<", "/etc/shadow")
    or return undef;
  my @users = <$filehandle>;
  return @users;
}

# ...

if (my @users = read_users($filename)) {
  print "Your system has $#users users\n";
  # process users
} else {
  croak "Cannot read shadow file";
}

The read_users() subroutine returns undef if it cannot open /etc/shadow, but it returns a list of user data entries if it succeeds. Since its output is used in list context, a return value of undef is converted to a list of a single element: (undef). Consequently, the if class returns true, and the system will incorrectly print out:

Your system has 0 users

Compliant Solution

This compliant solution uses a blank return rather than returning undef. Since a blank return is always interpreted as false in list or scalar context, the program will properly complain if it cannot read the shadow file.

sub read_users {
  open( my $filehandle, "<", "/etc/shadow")
    or return;
  my @users = <$filehandle>;
  return @users;
}

Exceptions

EXP00-EX1: This recommendation applies specifically to functions called in a list context. If you can guarentee that some function will never be called in a list context, then that function may return undef.

Risk Assessment

Improper interpretation of return undef can lead to incorrect program flow.

Automated Detection

Bibliography

[CPAN]. Elliot Shank, Perl-Critic-1.116. ProhibitOneArgSelect.
[Conway 2005], pg 199

EXP11-C. Do not apply operators expecting one type to data of an incompatible type      03. Expressions (EXP)      EXP13-C. Treat relational and equality operators as if they were nonassociative