6.4 Debugging Strategies

Imagine you've inherited a program, and when you go to run it, it doesn't work. (I know—what are the odds, eh? But let's pretend.) You need strategies for finding and fixing the problems.

6.4.1 Divide and Conquer

One of the simplest, yet most effective, techniques is to selectively remove as much of the code as possible until you've isolated the cause of an error message. If you can get the code down to a screenful, then even if you can't find the problem, other people to whom you show the code have a chance of being able to help you.

If you want to hide code temporarily (perhaps because you're not sure whether it's being used), then you can insert a line consisting precisely of:


__END__

(that's two underscores on each side and no leading or trailing white space) in your program, and everything that comes after it will be ignored (actually, it's available for reading via the DATA filehandle—make sure there isn't already an __END__ or __DATA__ line in the file). You can shuttle pieces of code in and out of that section.

Usually a syntax error is easy to locate because Perl tells you the line it occurred on, or the following line. Sometimes, however, the real culprit can be many lines earlier. If you're trying to locate the source of a really strange error that appears caused by bad syntax, you can move an __END__ line up and down the file in a binary chop and use perl's -c run-time flag to do syntax checking only (see perlrun).

To comment out a block of code in the middle of a file, use POD directives as described in Section 4.4.2.

When you're making modifications to how the program works, the golden rule to remember is this:

Change only one thing at a time!

You will go batty trying to figure out what caused strange new behavior if you make a whole slew of changes before trying the program out again. Once again the importance of having automated tests comes into the limelight.

For details on how to use Perl's run-time debugger, see Section 9.4.

Table of Contents