To get started with the debugger, return to Example 8-1 in Chapter 8. You’ll be putting a breakpoint on the first line of Main( ) to see how this code actually works. A breakpoint is an instruction to the debugger to stop running. You set a breakpoint, run the program, and the debugger runs the program up until the breakpoint. Then you have the opportunity to examine the value of your variables at this point in the execution. Examining your program as it runs can help you untangle otherwise impenetrable problems. You’ll often set multiple breakpoints, which allows you to skip through your program, examining the state of your object at selected locations.
You can set a breakpoint in many different ways. The easiest is to click in the left margin of the code window. This causes a red dot to appear in the margin next to the relevant line of code, which is also highlighted in red, as shown in Figure 9-1 (although you can’t see the color in the book). Open Example 8-1 from Chapter 8, if you haven’t already, and click in the gray margin next to the first line of Main( ) (Tester t = new Tester( )). Notice that as you hover over the breakpoint, a tool tip tells you the line on which the breakpoint appears.
You are now ready to run the program to the breakpoint. To do so, you must be sure to run in debug mode, which you can do by clicking the Start button (
) or by choosing the Start Debugging item from the Debug menu. In any case, the program starts and runs to the breakpoint, as shown in Figure 9-2.
Tip
Up until now, we’ve encouraged you to select Start Without Debugging so that your console window won’t vanish on you. If you want to use the debugger, though, you’ll need to “start with debugging,” obviously. Any breakpoint you set will keep your console window from vanishing.
The first thing to notice is that the program has stopped execution just before executing the statement with the breakpoint. In this case, that means the Tester object t hasn’t yet been created. Your console window is open, but blank, because your program hasn’t done anything yet. You’ll also notice that the red breakpoint symbol now has a yellow arrow in it. If you had more than one breakpoint in your program, the arrow would show you which one you’re stopped at now. The statement that’s about to be executed is highlighted in yellow to help you find it. Also, a number of helpful windows are open, and we’ll get to those in a moment.
Figure 9-1. Setting a breakpoint is easy; just click in the left margin. A red dot appears to show where the breakpoint is set.
The most useful feature of the debugger is the ability to step into the code, or execute the program one line at a time, watching the changes that happen with each line. To step into the code, press the F11 function key twice. With the first key press, the Tester object is created. The second key press moves you to the next line in the code, which calls the Run( ) method. Press the key once more to step inside the code for the Run( ) method where the program creates a new Box object, box1.
F11 and F10 are the step command keys. The difference is that F10 steps over method calls, whereas F11 steps into them. With F10, the methods are executed, but you don’t see each step within the method in the debugger; the highlighting jumps to the next statement after the method call. When you step into the method call with F11, on the other hand, the highlighting will move to the first line of the called method.
If you use F11 to step into a method you actually meant to step over, Shift-F11 will step you out. The method you stepped into will run to completion, and you’ll break on the first line back in the calling method.
In Visual Studio, but not C# Express, instead of clicking in the margin to set your breakpoint, you can use Debug → New Breakpoint → Break at Function (or use the keyboard shortcut for the menu item, Ctrl-D, N). This brings up the New Breakpoint dialog box, as shown in Figure 9-3. In this dialog box, you can specify the name of the method where you want to break, and even the line and character within the method, if you know them.
You can also examine and manipulate all the breakpoints together in the Breakpoints window, as shown in Figure 9-4. You can access this window in Visual Studio by selecting Debug → Windows → Breakpoints, or by pressing Ctrl-Alt-B. Unfortunately, this window is completely unavailable in C# Express, which is probably the greatest deficiency in its debugging suite.
The default behavior is for the breakpoint to cause the program to break every time you pass that line of code. Sometimes you only want to break (for example) every 20th time it passes that line of code, or only if the value of some variable is greater than, for example, 0. You can set conditions on the breakpoint by right-clicking on it in the Editor window or in the Breakpoints window, as shown in Figure 9-5.
Figure 9-3. The New Breakpoint dialog lets you set a breakpoint down to the character, if you want to be that precise.
Figure 9-4. The Breakpoints window lets you manage your breakpoints, but only if you’re using Visual Studio.
In C# Express, you’ll see only the first two options on this menu: Delete Breakpoint and Disable Breakpoint. In Visual Studio, you can choose either Hit Count or Condition. If you choose Hit Count, you are offered variations such as “break when the hit count is a multiple of”, as shown in Figure 9-6.
If you choose Condition, an open-ended condition text box is provided. In Figure 9-7, we have typed in theValue > 20 as an example.