Chapter 9. Run-time Exceptions

“When you have eliminated the impossible, that which remains, however improbable, must be the truth.”

—Sherlock Holmes in A Study in Scarlet, by Sir Arthur Conan Doyle

I remember when I was writing my first program in an independently-compiled language (Fortran; before that I was just using interpreted BASIC). After much work, I got the program to compile without any errors. In glee, I turned to a co-worker and said, “All right! I'm done now!” A grin came over his face, and he said, “I doubt it.” What awaited me at that point was the evil run-time error.

Perl is no slouch in the run-time error reporting department, and in fact, many errors that would occur at compile time in other languages happen at run time in Perl. For example, using a string in a numeric context: a strongly typed language would spot at compile time the attempt to assign a string to a numeric variable, but in Perl a scalar can switch between a string and a number according to whim.

We present here our bug-hunting approach to resolving run-time exceptions. There's no way to know whether you've gotten rid of all possible run-time bugs without running your program under every conceivable set of inputs and environmental changes that might possibly affect it.^[1]

^[1] Aside from proofs-of-correctness; but there again, proofs-of-correctness never seem to be attached to anything longer than 10 lines anyway.

The most basic run-time error is that the program refuses to execute at all. If you've been checking your program's syntax with Perl's -c switch, you might have a program that has no syntax errors but gives you the error “Permission denied” when you run it. This just means that you're running on Unix and have not yet set the execute permission for your program. You might also get “Command not found” even though you can see the program is there! Relax; this just means you have a typo in the first line of your program (the #! or “shebang” line), and it's saying it can't find the program you've put there. Perhaps you typed prel instead of perl again (or left out the space before the -w flag, which this author just did). While we're at it, you might also get an error looking like .nrecognized switch: -, which can drive you crazy until you discover that it's from running a program with DOS-style line terminations on Unix. Remove the ^Ms with a tool like dos2unix or perl -pi.bak -e 's/cM$//'.

The distinction between an error and an exception may have been hitherto glossed over in this book, but at this point we need to make it clear. An error simply means that something went wrong; for instance, a system routine may return a value indicating that it can't do what you have asked. A good program institutes some error handling at this point and checks the return code (more on this later). But the program is still running.

An exception occurs (is “thrown,” in the lingo) when some code declares that something intolerable has happened and Perl is simply not going to allow your program to continue running unless you specifically know how to handle (or “catch”) the exception. At this point, your program could be in the middle of some arbitrarily deep nesting of subroutine calls and {} blocks. It ceases executing wherever it is, and starts to percolate back up this stack looking at each level for anything declared that could catch this exception. If it gets all the way to the top without finding such a handler, it executes a default exception handler, which in Perl's case means printing a message with die and exiting.

Run-time exceptions from Perl may be built in, caused by use strict, or generated by you. The -w flag can cause a run-time warning message to be displayed, but your program will continue executing. If you've followed good coding practices, you should be worried about this possibility, since it may indicate that Perl is working with bad data (data that should be defined but isn't). If you want to make sure Perl halts when such a warning is generated, you can put this pseudo signal handler near the beginning of your program:^[2]

^[2] This is one of the few times where the difference between warn and print STDERR becomes apparent; the former is trapped by this sort-of signal handler, the latter is not.

local $SIG{__WARN__} = sub { die $_[0] }

and Perl exits after printing the warning.