It is much easier to make a mistake when writing a program containing branches and loops than it is when writing simple sequential programs. Even after going through the full design process, a program of any size is almost guaranteed not to be completely correct the first time it is used. Suppose that we have built the pro- gram and tested it, only to find that the output values are in error. How do we go about finding the bugs and fixing them?
Once programs start to include loops and branches, the best way to locate an error is to use the symbolic debugger supplied with MATLAB. This debugger is integrated with the MATLAB editor.
To use the debugger, first open the file that you would like to debug using the “File/Open” menu selection in the MATLAB Command Window. When the file is opened, it is loaded into the editor and the syntax is automatically color- coded. Comments in the file appear in green, variables and numbers appear in black, character strings appear in red, and language keywords appear in blue.
Figure 3.17 shows an example Edit/Debug window containing the file calc_roots.m.
Let’s say that we would like to determine what happens when the program is executed. To do this, we can set one or more breakpoints by right-clicking the mouse on the lines of interest and choosing the “Set/Clear Breakpoint” option.
When a breakpoint is set, a red dot appears to the left of that line containing the breakpoint, as shown in Figure 3.18 (see on page 140).
Once the breakpoints have been set, execute the program as usual by typing calc_rootsin the Command Window. The program will run until it reaches the first breakpoint and stop there. A green arrow will appear by the current line during the debugging process, as shown in Figure 3.19 (see on page 141). When the breakpoint is reached, the programmer can examine and/or modify any vari- able in the workspace by typing its name in the Command Window. When the programmer is satisfied with the program at that point, he or she can either step through the program a line at a time by repeatedly pressing F10 or else run to the next breakpoint by pressing F5. It is always possible to examine the values of any variable at any point in the program.
When a bug is found, the programmer can use the Editor to correct the MATLAB program and save the modified version to disk. Note that all break- points may be lost when the program is saved to disk, so they may have to be set again before debugging can continue. This process is repeated until the program appears to be bug-free.
Two other very important features of the debugger are found in the “Debug”
menu. The first feature is “Set/Modify Conditional Breakpoint.” A conditional breakpointis a breakpoint at which the code stops only if some condition is true.
For example, a conditional breakpoint can be used to stop execution inside a for loop on its 200th execution. This can be very important if a bug appears only after a loop has been executed many times. The condition that causes the breakpoint to
stop execution can be modified, and the breakpoint can be enabled or disabled during debugging.
The second feature is “Set Error Breakpoints for All Files.” If an error is occurring in a program that causes it to crash or generate warning messages, the programmer can turn this item on and execute the program. It will run to the point of the error and stop there, allowing the programmer to examine the values of variables and determine exactly what is causing the problem.
A final critical feature is found on the “Tools” menu. It is “Show M-Lint Report.” M-Lint is a program that examines one or more M-files and reports any 3.6 More on Debugging MATLAB Programs | 139
Figure 3.17 An Edit/Debug window with a MATLAB program loaded.
examples of improper or questionable usage. It is a greattool for locating errors, poor usage, or obsolete features in MATLAB code, including such things as vari- ables that are defined but never used. You should always run M-Lint over your programs when they are finished as a final check to ensure that everything has been done properly.
Take some time now to become familiar with the Editor/Debugger and its supporting tools—it is a very worthwhile investment.
Figure 3.18 The window after a breakpoint has been set. Note the red dot to the left of the line with the breakpoint.