|Do you know where your variables are?|
Re^3: package variables turning suddenly to undef and back again depending on subfunction callby flexvault (Prior)
|on Feb 26, 2013 at 10:28 UTC||Need Help??|
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:
At different places in the code, if I have something going wrong, I insert statements like:
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.
"Well done is better than well said." - Benjamin Franklin