I can debug my Perl program at almost any level I want, from inserting debugging code around that part I want to inspect, or tweaking it from the outside with an integrated development environment. I can even debug the program on a machine other than the one I run it on. I don’t have to stick with one approach, and might use many of them at the same time. If I’m not satisfied with the existing debuggers, I can even create my own and tailor it for my particular task.
Perl Debugged by Peter Scott and Ed Wright (Addison-Wesley) is one of the best books about actually programming with Perl. Not only do they show you how to effectively debug a Perl program, but they also show you how to not get yourself into some of the common traps that force you to debug a program. Sadly, this book appears to be out
of print, but don’t let the $1.99 price for a used version on Amazon.com color your notion of its usefulness.
Pro Perl Debugging (Apress) by Richard Foley tells you everything you need to know about the perl5db.pl debugger, which comes with Perl. If you like Perl’s default debugger, this book will tell you everything you want to know about it.
My first ever piece of Perl writing was a little piece for The Perl Journal number 9 called “Die-ing on the Web.” It’s available at my personal web site: http://www.pair.com/ comdog/Articles/Die_and_the_Web.txt.
I talk more about Hook::LexWrap in “Wrapping Subroutines” in the July 2005 issue of The Perl Journal. The article originally appeared in The Perl Journal and now appears in the “Lightweight Languages” section on Dr. Dobb’s Journal Online: http:// www.ddj.com/dept/lightlang/184416218.
The Practice of Programming by Brian W. Kernighan and Rob Pike (Addison-Wesley) discusses their approach to debugging. Although this isn’t a Perl book, it really doesn’t need to be about any language. It’s practical advice for any sort of programming.
* Larry Wall says that Laziness, Impatience, and Hubris are the principal virtues of a programmer, but those only work if the programmer is creating the code. Everyone else in the software development life cycle needs Tact, Humility, and Low Blood Pressure.
† In Chapter 10, I show how I do this with third-party modules, too: copy the source to a private directory I add to the front of @INC. I can edit that copy without worrying about breaking the original.
‡ I know I should wrap an eval around this, but I need an example where things go wrong. Even if I did wrap it in an eval, I still need to find the culprit passing the unexpected input.
§ It changes all of the calls, so if I’m using mod_perl I’ll end up changing it for every program since they share the same global variables. Oops.
‖ My __DIE__ handler can escape die’s further exception processing by using exit or another die, which won’t be special inside my handler. See perlvar’s discussion on %SIG for details.
#And I really mean mess. These functions both call Carp::longmess, and once you see the output, you’ll agree.
* This might mean that I have to install the Tk module too. Once installed, I also have to be able to display it in some sort of window manager. On my Powerbook, I use Apple’s X11 program (which is really XFree86
† The run method to Devel::ebug::Console concatenates with an empty string everything in @ARGV, so calling this example without the quotes tries to run the program named add_numbers.pl56 with no arguments.
‡ Once you get everything installed, but sure that you copy the root/ directory from the Devel::ebug::HTTP distribution to the same directory as the Devel::ebug::HTTP modules. Find that directory with perldoc -l
§ I can also guess the URL, since I know the name of the machine and can figure out which port it will use.
‖ The Eclipse Foundation (http://www.eclipse.org.
#Eclipse Perl Integration (http://e-p-i-c.sourceforge.net).
* Late Night Software (http://www.latenightsw.com).
blog comments powered by Disqus