Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^3: package variables turning suddenly to undef and back again depending on subfunction call

by flexvault (Parson)
on Feb 26, 2013 at 10:28 UTC ( #1020654=note: print w/ replies, xml ) Need Help??


in reply to Re^2: package variables turning suddenly to undef and back again depending on subfunction call
in thread package variables turning suddenly to undef and back again depending on subfunction call

tobias_hofer,

Just a little trick on using 'print' statements and debugging. (Note: I'm using *nix boxes) At the beginning of all of my packages, I define (actually copy the code) the following:

###################################################################### +# # DEBUG ==0 {no debugging}, ==1 {debugging}, >=2 {greater debugg +ing} ###################################################################### +## # our $Debug = 0; our $DLOG; ## Production our $Debug = 4; our $DLOG; ## Testing if ( $Debug ) { my $logFile = "MyLog_$$"; ## Good for multi-user testing open($DLOG,">",$logFile) || die "Cannot open $logFile:$!"; print $DLOG "############################# ".scalar localtime() +."\nStart. . . \n"; } else { open $DLOG, ">>", "/dev/null" ); }

At different places in the code, if I have something going wrong, I insert statements like:

for my $key { sort keys %Hash ) { ... do something ... if ( $Debug >= 4 ) { print $DLOG "Hash:\t$key\t|$Hash{$key}|\n +"; } }
Once you get it working, all you have to do to stop printing to the log, is change the '4' to a '5' and the print won't be executed. When computers were much slower than today, I used to take them out for production, but now I leave them in and change the global '$Debug' to '0'.

The advantage to doing this is if you have a production problem, you can turn the debugging on and get some help finding the problem. :-)

There have been times when I've had a debug statement after every line of code to figure out what was going wrong. It's usually a typo or some other simple mistake, but without the debug info, you just don't see it. ( I always use strict and warnings, but sometimes things get through. )

Always name the output so you can use your editor to search on the print statement. Notice that I put '|' around the variables to help see if it's undefined or "". You can also print to STDERR when your getting warnings. One time I was getting a couple 100K warnings for a script and by printing to STDERR, I was able to see the start and end of the problem in the loop. If your not testing a multi-user or multi-tasking package you don't need the '$$'. That's just so you don't have to lock/unlock the log file.

Good Luck...Ed

"Well done is better than well said." - Benjamin Franklin


Comment on Re^3: package variables turning suddenly to undef and back again depending on subfunction call
Select or Download Code
Re^4: package variables turning suddenly to undef and back again depending on subfunction call
by tobias_hofer (Friar) on Feb 26, 2013 at 11:40 UTC

    Hello Ed,

    I am doing almost the same, I wrote a class for error logging and use it extensively. For my module now I will give a try with your '$Debug' variable to drive the error-logging mechanism as its a fast way for exploring the data ;-)

    Thanks a lot!
    Tobias

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1020654]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (13)
As of 2014-07-23 14:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (144 votes), past polls