Debugging in the New IDE
Debugging in the New IDE Integrated debugging occurs in the Visual Studio IDE. There are also some external tools for debugging. DbgUrt.exe is a Common Language Runtime debugger, and Cordbg.exe is a CLR test debugger shell, a command-line debugging utility. The CLR includes a suite of extended debugging capabilities defined in the System.Diagnostics namespace. Diagnostics includes the Singleton Debug object, which includes Assert, and Writeline, which replaces Print. (Refer to Listing 1.2 for an example of the Writeline statement.) There are new methods in the Debug object for Tracing and much more. To give you a taste of the new power you will find in System.Diagnostics, Listing 1.8 provides a brief example of an attribute tag that instructs the debugger to disallow stepping into a method marked with this attribute. Listing 1.8 Using System.Diagnostics and a compiler attribute to disable stepping into a particular method1: Public Class Form1 2: Inherits System.Windows.Forms.Form 3: 4: #Region " Windows Form Designer generated code " 5: [ Windows Form Designer generated code here ] 6: Private Sub Form1_Load(ByVal sender As System.Object, _ 7: ByVal e As System.EventArgs) Handles MyBase.Load 8: SteppedOverCode() 9: End Sub 10: 11: #End Region 12: 13: #Region " My Stepped Over Code " 14: ' TODO: Add the discussion on attribute block delimiter 15: ' and system.diagnostics to chapter 12 on debugging. 16: <System.Diagnostics.DebuggerHidden()> Private Sub SteppedOverCode() 17: MsgBox("The debugger won't trace this subroutine") 18: End Sub 19; #End Region 20: 21: End Class Listing 1.8 conceals the Windows Form Designer-generated code except for the Form_Load event handler. OnLoad calls SteppedOverCode, which is in a user -defined region to facilitate outlining for this region of code. The SteppedOverCode subroutine is prefixed with a compiler attribute: <System.Diagnostics.DebuggerHidden()>. The effect of this attribute is that users won't be able to step into SteppedOverCode when debugging, demonstrating some of the new power extended to Visual Basic .NET developers. Chapter 12, "Defining Attributes," covers attributes in detail. Basic Debugging ShortcutsHere are a few salient debugging shortcuts, including the location of stack frame information. To Step Over code, press the Shift+F8 keys. To Step Into code, press F8, and to Step Out again, press Ctrl+Shift+F8. Step Out is a useful feature when you find yourself tracing a bunch of methods you really don't need to see. Press Shift+F11, and you will immediately be taken outside of the current procedure back to the calling procedure. The F9 key toggles a breakpoint, F5 starts the application in the IDE, and Shift+F5 restarts debugging. Use Ctrl+F5 to start the application without debugging it. All features described thus far are available on the Debug menu using the Visual Basic 6 profile. If you want to step into the disassembled code, using the F8 key will step into procedures as well as into disassembled code. I find the Stack Frame view useful for debugging. The Stack Frame view has been moved to the Debug Location toolbar; the Debug Location toolbar is displayed when you are debugging. The Stack Frame view is implemented as a drop-down list. The Stack Frame shows the methods called in order of most recent to least recent. You use the Stack Frame to view the path your code took to get to its current location. Debug, Disable All Breakpoints and Debug, and Enable All Breakpoints are the same menu item. When you disable a breakpoint, you turn it off without removing it; enabling all breakpoints has the opposite effect. This feature allows you to toggle breakpoints without finding and removing them. One of my favorite features is that breakpoints are maintained between sessions. This means that when you set a breakpoint in your code and close the solution, the breakpoint information is still set when you reopen the solution. Very nice. Structured Exception HandlingProbably the single most important tool for building robust applications is the addition of structured exception handling. Visual Basic .NET includes the Try...Catch...End Try and Try...Finally...End Try idioms for defining a structured exception-handling block and a resource protection block respectively. An exception-handling block is called when an error occurs and is used to write code to resolve the error. Try...Catch...End Try replaces the On Error...Goto from VB6. Try...Finally...End Try is for protecting resources, like file handles. The Finally clause of an exception handler is always called, ensuring that things like open files are closed properly. You can still use On Error...Goto in VB .NET, but its use is deprecated and is likely to be removed in the near future. You cannot use exception handling and On Error...Goto in the same procedure. Structured exception handling is a welcome addition to Visual Basic .NET. You will encounter examples throughout this book.  |
| | |
Team-Fly  |
| Top |
