When you are done programming and run your script, you want it to do what it was designed for. However usually it will not, it might produce unexpected results, probably because your code is not working the exact way you except it to do. If your program is over 10 lines and uses variables (like most script are!) then there are two things you can do to correct the code: a) Keep changing what could be wrong, running continually until you "get it right" b) Debug it.

 

icon_exclaim Bugs and syntax errors are different. Syntax errors are parts of the code perl cannot understand, and can be fixed using error testing. Bugs however are parts of the code that perl understands, but do not work as expected.

 

Debugging is like running, but slowly, at the pace you want, line by line usually, watching what exactly is happening with your code. While debugging, you can watch for example how variables change values or how the if statements work. It is like examining the tree rather than the entire forest.

 

After you design a script, development includes a cycles of coding and debugging. Upload to a production server only after you thoroughly tested your script.

 

When the debugger is started either using "Single Step" or "Continue Script", you will see the first line of your script get highlighted, and this will be the line about to be executed (we will call it the execution line). From here you can do the following (all selected from the Debug menu):

 

  • Single step. Selecting this will process the execution line. If the line calls a subroutine, then you will enter the subroutine.
  • Step over. Will process the execution line as above, but if it calls a subroutine, then the subroutine will also be called, without the flow to enter it.

 

These are the basic and important commands of the debugger.

 

  • Return from subroutine. If you are in a subroutine, it will be executed untill it ends, and return the execution line to the line after the line that called the subroutine. If you are not in a subroutine, then the script will be executed until it terminates.

 

  • Continue script. Like the above, but will execute your script until a breakpoint is found or termination even if the execution line is in a subroutine. This command can also be used to start the debugger.

 

  • Set Active Script. While editing and debugging, it is often useful to set an active script, especially if you are codeproofing modules that are invoked from a main script. In this case set the main script as active.

 

Often you know that a part of the script is correct, but need to debug a part after the good part. You don't need to trace every time the good part because you can use breakpoints:

 

  • Breakpoints. Enabled or disabled, by clicking on the gutter, next to the line you want to set as a breakpoint. If you have set a breakpoint in a subroutine, and the execution line is about to call this subroutine, then selecting "Step Over" will run the subroutine until it reaches the breakpoint, and this will become the execution line (the script will pause running again). In the same manner, selecting "Continue script", will stop on a breakpoint, if the program's flow passes over it.

 

Most perl programs also use modules. If the execution point is about to run a sub it a different module, then the other module will be opened in the editor, and show the new execution point.

 

icon_idea If you are using modules that are included in standard perl distribution, you know they work; they don't need any debugging. So if the subroutine you are calling in the execution line belongs to them, you can select "Step Over". This way you can avoid entering well known working code. You might want this of course if you are debugging your own modules.

 

icon_exclaim On some lines, there is no sense on adding a breakpoint, for example lines that contain only remarks, because these lines will never be executer. After the debugger loads, valid breakpoints are noted with a tick graphic in the gutter, while invalid have an x mark.

 

  • Viewing a value of an expression. An integral part of debugging is examining the value of a variable while the execution has stopped. If you have Auto-Evaluation enabled, hover the mouse over a variable or expression to see it's value. You can also select a part of the text and hover over the selection too see how this expression is evaluated.

 

icon_exclaim Note that the word under the cursor is evaluated OR the selected text under the cursor. Selecting first the text can help you evaluate expressions with spaces like:

 

print "<b>$k</b> = ".$ENV{$k}."<p>";

Select first the above expression and the hover the mouse on it.

 

  • Watches. See more in the Watches section.

 

Debugger's Status

 

The debugger's status is displayed in the status line of the main editor. Status can have the following values:

 

  • Not loaded: The debugger is not loaded. Press "Start Debugger" to load.
  • Stopped: The debugger has stopped on a line.
  • Processing: The debugger is processing a command you have sent it.
  • Terminated: The debugger has finished execution of the script.
  • Running: The script is running.

 

After your script terminates, you have an option to "Stop Debugger" or "Restart Debugger". If you will not be re-debugging your program, "Stop" is recommended, so that the debugger will be unloaded and the resources freed.

 

While running the script, all output is sent to the Web Browser, so you can view the output in either text or html format, by selecting the corresponding tab.

 

Your script might also read from <STDIN> (if for example it expects user input from the keyboard). If this happens, you will see that the status will be "Running", as the program is expecting user input. Enter the input in the edit box of the Web Browser and press "Send" to continue.

 

icon_exclaim If you are debugging locally, and have enable POST in the query editor, note that the for the first <STDIN> in your script there will be no wait, because OptiPerl feeded the STDIN with the Post data.

 

More advanced uses

 

While running the script or even after it has terminated (but with the debugger running) you may also execute the following:

 

  • List subroutine names
  • List variables in package
  • Methods callable

 

The above can be executed with entering a perl search pattern first or without

 

  • Evaluate expression: The result from this is identical to an expression entered in the watch window.

 

 

 

Top  Previous  Next