Many functions return useful values whether or not the function has side effects. In most cases, this value signifies whether the function successfully completed its task or if some error occurred. Other times, the value is the result of some computation and is an integral part of the function's API.
Because a return value often contains important information about possible errors, it should always be checked; otherwise, the cast should be made explicit to signify programmer intent.
Noncompliant Code Example
This noncompliant code example opens a file, reads in its information, and closes it again.
It makes sure the variable containing the file name is properly defined, but it does nothing else to catch errors. Consequently, any error, such as the file not existing, being unreadable, or containing too much data to read into memory, will cause the program to abort.
This compliant solution does the same thing but provides useful error messages if anything goes wrong.
If any error occurs, the program calls the
croak() function, passing it a string that includes both the source file being opened and the
$! variable, which contains a system error string based on the value of
errno, which is set to a useful value when the
close(2) functions fail.
EXP32:EX0: If the return value is inconsequential or if any errors can be safely ignored, such as for functions called because of their side effects, the function's return value may be silently discarded.
autodie module is designed to replace functions that return a value indicating failure with functions that throw an exception on failure. When
autodie is in use, any functions it redefines may be safely ignored.
EXP32:EX2: Functions that send data to standard output or standard error need not have their return values checked. This includes
printf, but only if their file handle argument is not supplied or is explicitly set to
*STDERR. If they send their output to any other file handle, their return value must be checked.
EXP32:EX3: When inside error-handling code, function calls that are used to release resources, such as
close(), need not have their return values checked. Any code that falls under this exception should be explicitly documented as such.
Failure to handle error codes or other values returned by functions can lead to incorrect program flow and violations of data integrity.