Section 13.14. Unpacking Exceptions

13.14. Unpacking Exceptions

Unpack the exception variable in extended exception handlers.

If an exception handler becomes long or complex, you may need to refactor parts of it. For example, consider the X::EOF handler inside TRy_next_line( ) from the "OO Exceptions" guideline:

      sub try_next_line {         
# Give get_next_line(  ) two chances...
         for my $already_retried (0..1) {             
# Return immediately on success, but catch any failure...
             eval {                 return get_next_line(  )             };             
# Rethrow the caught exception if it isn't an EOF problem...
             croak $EVAL_ERROR                 if !X::EOF->caught(  );             
# Also rethrow the caught exception             # if we've already tried rewinding the filehandle...
             croak $EVAL_ERROR                 if $already_retried;             
# Otherwise, try rewinding the filehandle...
             seek $EVAL_ERROR->handle(  ), 0, 0;         }     }

This code would seem to be cleaner and easier to extend if the separate rethrows were refactored like this:

     sub try_next_line {         # Give get_next_line(  ) two chances...         for my $already_retried (0..1) {             # Return immediately on success, but catch any failure...             eval {                 return get_next_line(  )             };             # If we can handle this exception...             if (X::EOF->caught(  ) ) {                 # Fail on irremedially bad cases...                 fail_if_incorrigible($EVAL_ERROR, $already_retried);                 # Otherwise, try rewinding the filehandle...                 seek $EVAL_ERROR->handle(  ), 0, 0;             }             # Otherwise, let some caller handle it...             else {                 $EVAL_ERROR->rethrow(  );             }         }     }

Refactoring in this way is usually a highly recommended practice, but in this case it has the potential to introduce a subtle bug. The problem is that the $EVAL_ERROR exception variable (a.k.a. $@) is a global variable. So if fail_if_incorrigible( ) happens to throwand then internally catchsome other exception during its execution, that nested exception will overwrite $EVAL_ERROR.

So, after the call to fail_if_incorrigible( ), the exception variable might still have the original X::EOF exception, or it might contain some other totally unrelated exception, left over from the internal machinations of fail_if_incorrigible( ). That uncertainty makes the seek statement after the call to fail_if_incorrigible( ) problematic. It tries to seek the handle that was sent back inside the original exception, but there's now no guarantee that $EVAL_ERROR still contains that exception.

Fortunately, it's comparatively simple to solve this problem: just copy the exception into a lexical variable before attempting to handle it:

      if (X::EOF->caught(  ) ) {         my $exception = $EVAL_ERROR;         
# Fail on irremedially bad cases...
         fail_if_incorrigible($exception, $already_retried);         
# Otherwise, try rewinding the filehandle...
         seek $exception->handle(  ), 0, 0;     }

Using the Exception::Class module makes this practice even easier to follow, because its version of the caught( ) method always returns a copy of $EVAL_ERROR on success. So you can just write:

      if (my $exception = X::EOF->caught(  ) ) {         
# Fail on irremedially bad cases...
         fail_if_incorrigible($exception, $already_retried);         
# Otherwise, try rewinding the filehandle...
         seek $exception->fh(  ), 0, 0;     }