Re: brian's Guide to Solving Any Perl Problem

[ff]

The best debugger in the universe is print.

        print STDERR "The value is [$value]\n";

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.

/^warn

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

cluck

statements at the start of a line (a la warn) helps me figure out just how a particular subroutine got invoked.

[brian_d_foy]

I use warn() for program warnings rather than debugging output.

However, if I'm doing really big things, I usually have a debug() or trace() function lying around.

[dragonchild]

However, if I'm doing really big things, I usually have a debug() or trace() function lying around.

But not a log() function. (Don't laugh, I've been bitten by this one.)

[ff]

Of course it's fine to save warn() for "real" error messages, but then the same could be said for only using print() for real output messages.

My problem, for which I'd welcome suggestions, is that I'm not familiar with how to use debug() in the midst of debugging a huge Tk-based application that I'm working on. The subroutines I am debugging get fired when I click one of the Tk buttons, and I know for sure that I can get at my warn() messages as above via my STDERR files. Out of ignorance, I'm just expecting use of debug() to be impractical.

[brian_d_foy]

The debug() function can be whatever you want it to be, because you have to write it.

The print() loses against warn() because I can redefine the behaviour of warn() without changing the statements.

[Bloodnok]

A most enlightening post, if I may say so, brian_d_foy.

I also used to use warn() until I realised that, when re-running Test::* based modules, it [the use of warn()] 'gets in the way' of true warnings - ever since when I, like you, define an additional sub to printf STDERR ... - thus the code behaves as I think it should whilst still generating debugging messages that don't cause test case failures.