Re^3: I never use the debugger.

There's nothing to say you can't do a hybrid approach if you're debugger is being annoying... which the perl debugger is sometimes. :-(

Add a debugging conditional for the nth line of the loop, and set a breakpoint at it.

In my experience, though, if I'm interested in the thousandth interation of something, there's something happening (a particular record, or database entry, or something) that triggers my interest in the 1,000th time through the loop versus the 999th time.

If I can identify what that is, I can write debug code to detect the suspicious condition, and set a breakpoint for that. Then I can decide what to print out, and where to investigate from there.

Unfortunately, the perl debugger doesn't seem to have a "detect this condition and break" function, and I sure wish it did. I consider it a flaw in the debugger when I have to write debug code by hand, but it's better than writing *all* the debug code by hand, only to tear it *all* out later...

Comment on Re^3: I never use the debugger.

Replies are listed 'Best First'.
Re^4: I never use the debugger. by Tanktalus (Canon) on Jul 27, 2005 at 21:52 UTC
Hmmm? `b My::App::some_function $_[3] > 999` [download] Sets the breakpoint on My::App::some_function only if the 4th argument is numerically larger than 999. Similar structure for line breaks: `b 215 $i > 999` [download] I use it all the time. It's invaluable.	[reply] [d/l] [select]
Re^5: I never use the debugger. by Anonymous Monk on Jul 28, 2005 at 16:55 UTC
The documentation on that feature has changed: it used to read "b <linenumber> <expr>", and no matter what I tried, the debugger wouldn't stop, not even with b <linenumber> 1, so I gave up on it years ago. You're saying it's a stable, reliable feature now? A debugger feature that doesn't work is worse than none, really...	[reply]