It's been nearly ten years since I've said anything here. Somehow, this seems appropriate.
I, as many perl hackers have, tend default to quick "print" statements for debugging, only to be shot down when throwing my code at, say, multiple input files at once, for example. No longer.
Sure, your code works for *most* of the files, but something is twitchy somewhere. Unicode when you expected ASCII. A mix of LF/CRLF line endings. CR line endings (horrors!) even :)
But: if you print where you think things are going wrong, that output goes in the STDOUT queue. The errors that pop when things go wrong happen in the STDERR queue. Hence, "warn" is your bestest friend evars! Trust me on this. You'll get all sorts of win using "warn" context points when you want to debug via print-ing.
Re: "warn" is your best friend
by kcott (Archbishop) on Mar 23, 2014 at 05:37 UTC
|
G'day snax,
Welcome back after your decade-long sabbatical.
Yes, I agree warn can be quite handy in this sort of situation.
It also allows you to quickly search your code for development debugging statements and, for production code, remove them, comment them out, or even convert them for whatever standard debugging/logging system is being used.
While I'm sure you're aware of it, I thought I'd just point out carp() and cluck() (from the built-in Carp module).
These also output to STDERR and, depending on your requirements, may produce more useful information.
| [reply] [d/l] [select] |
Re: "warn" is your best friend
by moritz (Cardinal) on Mar 23, 2014 at 08:02 UTC
|
Since you mentioned Unicode: Many Perl programs these days set up STDOUT correctly to encode the output, but forget to the same with STDERR (and yes, I myself am guilty of this many times over).
So when debug-outputting non-ASCII strings to STDERR, you need to be extra aware of encoding issues.
(That said, when debugging encoding issues, I usually set $Data::Dumper::Useqq = 1 and debug with Data::Dumper, so it's not that much of an issue; but if you want to warn plain strings, you must be aware of it).
| [reply] [d/l] |
Re: "warn" is your best friend
by Bloodnok (Vicar) on Mar 23, 2014 at 12:08 UTC
|
| [reply] [d/l] |
|
| [reply] [d/l] [select] |
|
Hiya tobyink,
Much as tho' I like and indeed really appreciate, your insight into debugging the test cases, I was actually referring to the use of spurious debugging statement(s) in the code itself - where my use of warn suggested that the code was even more broken than and in a different place to, the actual problem.
A user level that continues to overstate my experience :-))
| [reply] |
|
|
|
Re: "warn" is your best friend
by GrandFather (Saint) on Mar 25, 2014 at 00:55 UTC
|
Actually I find a good IDE, breakpoints and variable contents viewing a lot more powerful and much faster than any sort of print/warn/::diag/Carp/... based technique. Even the Perl command line debugger is vastly quicker for resolving issues than any print based technique (I used Perl's command line debugger for the first time in 3 years yesterday and was sufficiently up to speed with it in 10 minutes).
I use Carp for reporting bad states (unexpected parameters for example) and die for exception handling internally. Those often point to areas where a little debugging is required, but then it's set a breakpoint and inspect the state directly - even changing variable contents on the fly to explore issues further. For me with, any half decent development environment available, print based debugging stopped 30 years ago.
If the code changes take longer than the time saved, it's fast enough already.
| [reply] |
|
Actually, it's best to just log everything.
And yes, you are right, there had been vim and emacs available 30 years ago.
| [reply] |
|
ugh, reading talks like this make me wonder why anyone uses java...
| [reply] |
|
|