X hits on this document

PDF document

Running and Debugging Perl - page 24 / 30





24 / 30

Chapter 9

Command n


Step over a subroutine. Call the subroutine reference on the current line, and stop again once control has returned from that.

Return r c

Repeat the last stepping command. Keep going until the current subroutine returns.

Continue – keep going until something happens that causes the debugger to stop again.

l - w /pattern/ t b

List the next few lines to be processed. List the previous lines processed. List the lines around the current line. Search forwards in the program code until the pattern matches. Turn on (or off) trace mode. This prints every statement before executing it.

Set a breakpoint. Stop running the program and return to the debugger at the given line number or when the given condition is true.


Evaluate something in array context and give a tree view of the resulting data structure.

! p h

Do the previous command again. Print something out. Get more help.

We're not going to look any further at the debugger. While it can help you out – and once you start really developing in Perl it really will – for the time being it's a better learning experience to try and debug your code using the hints and techniques shown in the rest of this chapter. That way you can really get to know how Perl thinks and works.

Defensive Programming

Far and away the best way to debug your code is to try and make sure you never have to. While it's impossible to guarantee that there will never be any bugs in your program, there are a lot of things you can do to minimize their number, and to make sure that any potential bugs are easy to locate. In a sense, it's all about expecting the worst.


Before writing another line, make sure you've got a plan. You need to use just as methodical an approach to debug code efficiently as you do to write it in the first place. Keep the following points in mind:

Never try to write a large program without trying parts of that program first. Break the task down into small units, which can be tested as they're written.

Track down the first bug, then try the program again – the second may just have been a consequence of the first one.


Document info
Document views45
Page views45
Page last viewedSun Oct 23 03:13:45 UTC 2016