|There's more than one way to do things|
Re: brian's Guide to Solving Any Perl Problemby ff (Hermit)
|on Jul 25, 2004 at 05:34 UTC||Need Help??|
The best debugger in the universe is print.
To which I'd add, while not earthshaking or original, that I like using warn even more than print STDERR. Besides being shorter, the fact that it's different makes it easier to find such statements and comment out those lines when I'm through with them.
More particularly, I put my debugging 'warn' messages at the start of a line. Since most of my perl code has been indented a couple of tabs away from column 1, the fact that these statements are 'debug' type statements stands out. And since I might want to reuse the same debugging statements from time to time, rather than erase them when I'm done, I just comment them out when I'm "through" with them. This way, when I'm desparate later to know what's happening in some region, those previously written warn statements are there, waiting to be uncommented. And if I uncomment seven or eight of them (among the dozens/hundreds in my code :-), I can easily find them again to turn them off when I'm done with them by doing a vim search for them at the start of a line.
Then repeat my search with n and repeat my 'uncomment' with a dot. Because these statements are at the start of a line, they can be found differently than the warn statements that are in the clear and are SUPPOSED to fire when triggered by real problems.)
I also find that including
use Carp qw(cluck);
early in my program and using
statements at the start of a line (a la warn) helps me figure out just how a particular subroutine got invoked.