How can I cleanly handle error checking in Perl?

Question

I have a Perl routine that manages error checking. There are about 10 different checks and some are nested, based on prior success. These are typically not exceptional cases where I would need to croak/die. Also, once an error occurs, there's no point in running through the rest of the checks.

However, I can't seem to think of a neat way to solve this issue except by using something analogous to the following horrid hack:

sub lots_of_checks
{

 if(failcond)
 {
  goto failstate:
 }
 elsif(failcond2)
 {
  goto failstate;
 }

 #This continues on and on until...

 return 1; #O happy day!

 failstate:

 return 0; #Dead...
}

What I would prefer to be able to do would be something like so:

do
{
 if(failcond)
 {
  last;
 }
 #...
};

Answer 1

Perhaps you want to have a look at the following articles about exception handling in perl5:

• perl.com: Object Oriented Exception Handling in Perl
• perlfoundation.com: Exception Handling in Perl

Answer 2

An empty return statement is a better way of returning false from a Perl sub than returning 0. The latter value will actually be true in list context:

sub lots_of_checks {
    return if fail_condition_1;
    return if fail_condition_2;
    # ...
    return 1;
}

Answer 3

Given your example, I'd write it this way:

sub lots_of_checks {
    local $_ = shift;  # You can use 'my' here in 5.10+

    return if /condition1/;
    return if /condition2/;
    # etc.

    return 1;
}

Note the bare return instead of return 0. This is usually better because it respects context; the value will be undef in scalar context and () (the empty list) in list context.

If you want to hold to a single-exit point (which is slightly un-Perlish), you can do it without resorting to goto. As the documentation for last states:

... a block by itself is semantically identical to a loop that executes once. Thus "last" can be used to effect an early exit out of such a block.

sub lots_of_checks {
    local $_ = shift;
    my $all_clear;

    {
        last if /condition1/;
        last if /condition2/;
        # ...
        $all_clear = 1; # only set if all checks pass
    }

    return unless $all_clear;
    return 1;
}

Answer 4

You absolutely can do what you prefer.

Check: {
    last Check
        if failcond1;
    last Check
        if failcond2;
    success();
}

Answer 5

If you want to keep your single in/single out structure, you can modify the other suggestions slightly to get:

sub lots_of_checks
{
    goto failstate if failcond1;

    goto failstate if failcond2;

    # This continues on and on until...

    return 1; # O happy day!

    failstate:

    # Any clean up code here.

    return; # Dead...
}

IMO, Perl's use of the statement modifier form "return if EXPR" makes guard clauses more readable than they are in C. When you first see the line, you know that you have a guard clause. This feature is often denigrated, but in this case I am quite fond of it.

Using the goto with the statement modifier retains the clarity, and reduces clutter, while it preserves your single exit code style. I've used this form when I had complex clean up to do after failing validation for a routine.

Answer 6

Why would you not use exceptions? Any case where the normal flow of the code should not be followed is an exception. Using "return" or "goto" is really the same thing, just more "not what you want".

(What you really want are continuations, which "return", "goto", "last", and "throw" are all special cases of. While Perl does not have full continuations, we do have escape continuations; see http://search.cpan.org/~sartak/Continuation-Escape-0.03/lib/Continuation/Escape.pm)

In your code example, you write:

do
{
 if(failcond)
 {
  last;
 }
 #...
};

This is probably the same as:

eval {
   if(failcond){
       die 'failcond';
   }
}

If you want to be tricky and ignore other exceptions:

my $magic = [];
eval {
    if(failcond){
        die $magic;
    }
}
if ($@ != $magic) {
    die; # rethrow
}

Or, you can use the Continuation::Escape module mentioned above. But there is no reason to ignore exceptions; it is perfectly acceptable to use them this way.