Is adding print lines the only way to go to find computational error in a scrpt?

[Elias]

Is adding print lines the only way to go to find computational error in a scrpt?

Originally posted as a Categorized Question.

[davorg]

No. Perl has a built-in debugger for that.

Get more details from perldoc perldebug.

Originally posted as a Categorized Answer.

[neophyte]

If you have trouble using the built-in debugger (see perldoc perldebug), check out the tutorial Using the Perl Debugger on this site.

Originally posted as a Categorized Answer.

[chipmunk]

The only way? Absolutely not. I know that adding print lines is the preferred method of debugging for some people, but in my mind an actual debugger is by far the best tool.

Advantages for print statements:

1. Simple - don't need to learn anything new.
Advantages for a debugger:
1. Powerful - stepping, (conditional) breakpoints, actions, watchpoints, etc.
2. Versatile - examine any value -- or the result of any expression -- at any point.
3. Informative - dump complicated data structures, view stack traces, etc.
When perl5.6.1 is released, it will include a tutorial on using the debugger, written by Richard Foley.

Editor's note: thanks to davorg and neophyte for the following information (combined into one answer for better reference):
If you have trouble using the built-in debugger (see perldoc perldebug), check out the tutorial Using the Perl Debugger on this site.

[cLive ;-)]

If your code doesn't crash at shell, but causes a 500 error in browser, use this at the top of your script:

use CGI::Carp qw(fatalsToBrowser);

It doesn't catch everything though.

[idle]

One more way, adding at the top of script: BEGIN {open (STDERR, ">>/path/error.log")}

[hexcoder]

Lets assume, you want to use the debugger. Then the problem might be to get the debugger to break after a warning condition happened.

The warnings contain a line number which is fine, but when the line is part of a loop, this is not enough information. We would want a stop with the current context. Only then can we examine the state of the program in the context that produced the problem.

So what to do?
I replace the signal handler for SIGWARN with my own handler that checks for the typical format of a Perl warning. I do that because I am interested only in warnings from the Perl interpreter. If this format has been detected, the code branches into a special path where we can setup the debugger. We want the debugger to stop and to return to the caller, where there warning was caused. So we set a variable that causes the debugger to stop. This will take effect when the signal handler has returned. After that setup stage, the warning message is printed as before the modification.

The signal handler code should go into the debugger initialization file .perldb. Then I do not have to modify the original source code.

This is the content of file .perldb (place it in the current or in the home directory):

sub afterinit 
{
    $::SIG{'__WARN__'} = sub {
        my $warning = shift;
        if ( $warning =~ m{\s at \s \S+ \s line \s \d+ \. $}xms ) {
            $DB::single = 1;    # debugger stops automatically after
            # the line that caused the warning.
        }
        warn $warning;
    };
    print "sigwarn handler installed!\n";
    return;
}

Note: This is mostly stolen from my writeup Re: Debugging a program and Re^3: Debugging a program, but I think it fits better here.