Working With Breakpoints and the Debugging Tools
You can mark lines of code where the test run of an application should pause. This might be useful to, for example, make sure that a method really enters an if-statement, to make sure that a method actually ran, and to inspect or modify values of local variables for debugging purposes. You can mark a line of code in this way by adding a breakpoint to a line by clicking in the margin to the left of the line numbers, by right-clicking the line number and choosing Add Breakpoint, or by pressing Ctrl+B while on the line where you want to add a breakpoint. The margin is then marked with a red dot that indicates the breakpoint. Note that clicking next to an empty line will not add a breakpoint — the line has to contain a statement for the breakpoint to make sense.
Figure 4-9: A Method Editor window with a breakpoint at line 4.
To remove a breakpoint, click it again, press Ctrl+B again, or right-click the line number and choose Remove Breakpoint. All breakpoints can be removed in one action by using the Remove All () button in the Breakpoints section of the Method ribbon tab. Sometimes, it is convenient to make the test run of an application ignore the existing breakpoints. In such a case, right-click the line number and choose Disable Breakpoint or press Ctrl+Shift+B. You can also disable all breakpoints using the Disable All () toggle button. Disabled breakpoints are indicated by an empty red circle when you disable individual breakpoints and with a diagonal black line when you disable all breakpoints. Press Ctrl+Shift+B again or click the Disable All () button again to enable a single disabled breakpoint or to enable all breakpoints, respectively. You can also use the Breakpoints window to manage the breakpoints; see Viewing and Modifying All Breakpoints.
Figure 4-10: A disabled breakpoint on line 3 in the editor for method2.
If you run a method during the test run of an application, the Method Editor window is open, and the method has an enabled breakpoint, then the method will stop running on the line of the breakpoint. The entire line then becomes highlighted, and the Continue (), Step (), Step Into (), and Step Out () buttons are enabled in the Debug ribbon tab. The Continue and Step buttons are only available when the debugger is paused.
Figure 4-11: The debugger is stopped at a breakpoint, and the Continue, Step and other buttons in the Debug section are available. The code uses a debugLog method to print debugging information to the Debug Log.
If you click the Continue button (or press F5), the method continues to run until it completes or reaches another breakpoint. If you click the Step button (or press F6), the method continues to run until the next line, where it stops again, giving you the options to continue or step. The Step Into button works in the same way as the Step button. However, if the line contains a call to another method or utility method, clicking Step Into (or pressing F7) then takes you to the first line in that method instead of continuing to the next line in the current method. Click Step Out (or press Ctrl+F7) to step out from the current method. Click the Break button (or press Pause) to suspend the current running method at the next reached line in method code, as if there had been a breakpoint there. There is also a Stop button, which is available when you start to run a method. Clicking (or pressing Ctrl+Pause) it forces the current method to stop. It can be useful if you want to stop the debugging run immediately or if the method runs into an endless loop, for example.