You can write your own mini (or micro) debuggers to watch your program run. You might want to do this when the other Perl debuggers are too heavyweight (or even too interactive) for your immediate problem. Continue reading “Trace your Perl programs”
Category: debugging
Use Data::Printer to debug data structures
You can use several different Perl modules to inspect data structures. Many of these modules, however, are really two tools in one. Besides showing a data structure as a string, they also serialize the data as Perl code so you can reconstruct the data structure. That second job often makes things hard for you. If you don’t need the serialization job, don’t use a module that insists on it. Continue reading “Use Data::Printer to debug data structures”
Intercept warnings with a __WARN__ handler
Perl defines two internal pseudo-signals that you can trap. There’s one for die, which I covered in Override die with END or CORE::GLOBAL::die and eventually told you not to use. There’s also one for warn that’s quite safe to use when you need to intercept warnings. Continue reading “Intercept warnings with a __WARN__ handler”
Use Data::Dump filters for nicer pretty-printing
Data::Dumper, a module that comes in the Standard Library, is one of the great tools knows to Perlers. You give it a big data structure and it pretty prints it for you. If you are one of those people who still believe that the best debugger in the world is print and need to get data structures into a single string with decent formatting, something like Data::Dumper is your best friend. When you get really complex data structures involving complicated objects, though, dumping the entire structure might be too much information. Continue reading “Use Data::Dump filters for nicer pretty-printing”
Locate bugs with source control bisection
As you work in Perl you store each step in source control. When you finish a little bit of work, you commit your work. Ideally, every commit deals with one thing so you’re only introducing one logical change in each revision. Somewhere along the process, you might discover that something is not working correctly. You think that it used to work but you’re not sure where things went pear-shaped, perhaps because the bug seemingly deals with something that you weren’t working on. Continue reading “Locate bugs with source control bisection”
Detect regular expression match variables in your code
[UPDATE: this is not a problem in v5.18 and later.]
In Item 33: “Watch out for match variables”, you found out that the match variable $`, $&, and $` come with a performance hit. With all of the module code that you might use, you might be using those variables even though you didn’t code with them yourself. Continue reading “Detect regular expression match variables in your code”
Use Carp::REPL as an interactive Perl shell.
Wouldn’t it be great if you could stop your program right before it died so you could see what’s causing the problem? You could start the Perl debugger and step your way to the problem, or set up some break points, but that’s often too much work. The Carp::REPL module let’s you drop into a debugger just at the point you need. Continue reading “Use Carp::REPL as an interactive Perl shell.”
Use B::Deparse to see what perl thinks the code is.
We used B::Deparse in Item 7. Know which values are false and test them accordingly, but we didn’t say much about that module. The B namespace has many modules that do various nasty black magic things with the perl parse tree. Continue reading “Use B::Deparse to see what perl thinks the code is.”