Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re: brian's Guide to Solving Any Perl Problem

by ff (Hermit)
on Jul 25, 2004 at 05:34 UTC ( #377228=note: print w/replies, xml ) Need Help??

in reply to brian's Guide to Solving Any Perl Problem

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.


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.

Replies are listed 'Best First'.
Re^2: brian's Guide to Solving Any Perl Problem
by brian_d_foy (Abbot) on Jul 25, 2004 at 06:02 UTC
    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.

    brian d foy <>
      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.)

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      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.

        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.

        brian d foy <>
      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.

      A user level that continues to overstate my experience :-))

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://377228]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2017-03-29 23:19 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (353 votes). Check out past polls.