This chapter is from the book
This chapter is from the book
This chapter is from the book
Debugging Overview
In this section you get an overview of the debugging features in Visual Studio 2012 for Visual Basic applications. Although the debugger and debugging techniques are detailed in Chapter 5, “Debugging Visual Basic 2012 Applications,” here we provide information on the most common debugging tasks, which is something that you need to know in this first part of your journey through the Visual Basic programming language.
Debugging an Application
To debug a Visual Basic application, you basically need to perform two steps:
- Enable the Debug configuration in the compile options.
- Press F5 to start debugging.
By pressing F5, Visual Studio runs your application and attaches an instance of the debugger to the application. Because the Visual Studio debugger needs the debug symbols to proceed, if you do not choose the Debug configuration, you cannot debug your applications. The instance of the debugger detaches when you shut down your application.
The debugger monitors your application’s execution and notifies for runtime errors; it allows you to take control over the execution flow as well. Figure 2.28 shows our sample application running with the Visual Studio debugger attached.
)
Figure 2.28. Our sample application running with an attached instance of the Visual Studio debugger.
In the bottom area of the IDE, you can notice the availability of some tabs, such as Locals, Watch 1, Watch 2, Call Stack, Breakpoints, Command Window, Immediate Window, and Output. Each tab represents a tool window that has specific debugging purposes. Also, notice how the status bar becomes orange and an orange border is placed around the IDE, to remind the developer that the IDE is running in debugging mode. The Visual Studio debugger is a powerful tool; next you learn the most important tasks in debugging applications. Before explaining the tooling, it is a good idea to modify the source code of our test application so that we can cause some errors and see the debugger in action. We could rewrite the Sub Main method’s code, as shown in Listing 2.3.
Listing 2.3. Modifying the Sub Main for Debugging Purposes
Sub Main()
'A text message
Dim message As String = "Hello Visual Basic 2012!"
Console.WriteLine(message)
'Attempt to read a file that does not exist
Dim getSomeText As String =
My.Computer.FileSystem.ReadAllText("FakeFile.txt")
Console.WriteLine(getSomeText)
Console.ReadLine()
End Sub
The code simply declares a message object of type String, containing a text message. This message is then shown in the Console window. This is useful for understanding breakpoints and other features in the code editor. The second part of the code will try to open a text file, which effectively does not exist and store its content into a variable called getSomeText of type String. We need this to understand how the debugger catches errors at runtime, together with the edit and continue feature.
Breakpoints and Data Tips
Breakpoints enable you to control the execution flow of your application. A breakpoint breaks the execution of the application at the point where the breakpoint itself is placed so that you can take required actions (a situation known as break mode). You can then resume the application execution. To place a breakpoint on a specific line of code, just place the cursor on the line of code you want to debug and then press F9.
A breakpoint is easily recognizable because it highlights in red the selected line of code (see Figure 2.29).
)
Figure 2.29. Placing a breakpoint in the code editor.
To see how breakpoints work, we can run the sample application by pressing F5. When the debugger encounters a breakpoint, it breaks the execution and highlights in yellow the line of code that is being debugged, as shown in Figure 2.30, before the code is executed.
)
Figure 2.30. When encountering a breakpoint, Visual Studio highlights the line of code that is currently debugged.
If you take a look at Figure 2.30, you notice that, if you pass with the mouse pointer over the message variable, IntelliSense shows the content of the variable itself, which at the moment contains no value (in fact, it is set to Nothing). This feature is known as Data Tips and is useful if you need to know the content of a variable or of another object in a particular moment of the application execution.
You can then execute just one line of code at a time, by pressing F11. For example, supposing we want to check if the message variable is correctly initialized at runtime. We could press F11 (which is a shortcut for the Step Into command in the Debug menu). The line of code where the breakpoint is placed will now be executed, and Visual Studio will highlight the next line of code. At that point, you can still pass the mouse pointer over the variable to see the assignment result, as shown in Figure 2.31.
)
Figure 2.31. Using the Step Into command lets us check whether the variable has been assigned correctly.
When you finish checking the assignments, you can resume the execution by pressing F5. The execution of the application continues until another breakpoint or a runtime error is encountered. We discuss this second scenario next.
Runtime Errors
Runtime errors are particular situations in which an error occurs during the application execution. These are not predictable and occur due to programming errors that are not visible at compile time. Typical examples of runtime errors are when you create an application and you give users the ability to specify a filename, but the file is not found on disk, or when you need to access a database and pass an incorrect SQL query string. Obviously, in real-life applications you should predict such possibilities and implement the appropriate error handling routines (discussed in Chapter 6, “Handling Errors and Exceptions”), but for our learning purposes about the debugger, we need some code that voluntarily causes an error. Continuing the debugging we began in the previous paragraph, the application’s execution resumption causes a runtime error because our code is searching for a file that does not exist. When the error is raised, Visual Studio breaks the execution as shown in Figure 2.32.
)
Figure 2.32. The Visual Studio debugger encounters a runtime error.
As you can see, the line of code that caused the error appears highlighted. You also can see a pop-up window that shows some information about the error. In our example, the code searched for a file that does not exist, so a FileNotFoundException was thrown and was not handled by error handling routines; therefore, the execution of the application was broken. Visual Studio also shows a description of the error message. (In our example it communicates that the code could not find the FakeFile.txt file.) Visual Studio also shows some suggestions. For example, the Troubleshooting tips suggest some tasks you could perform at this point, such as verifying that the file exists in the specified location, checking the pathname, or getting general help about the error. By clicking a tip, you are redirected to the MSDN documentation about the error. This can be useful when you don’t exactly know what an error message means. There are other options within the Actions group. The most important is View Detail. This enables you to open the View Detail window, which is represented in Figure 2.33. Notice how the StackTrace item shows the hierarchy of calls to classes and methods that effectively produced the error. Another interesting item is the InnerException. In our example it is set to Nothing, but it’s not unusual for this item to show a kind of exceptions tree that enables you to better understand what actually caused an error. For example, think of working with data. You might want to connect to SQL Server and fetch data from a database. You could not have sufficient rights to access the database, and the runtime might return a data access exception that does not allow you to immediately understand what the problem is. Browsing the InnerException can help you understand that the problem was caused by insufficient rights. Going back to the code, this is the point where you can fix it and where the Edit and Continue features comes in.
)
Figure 2.33. The View Detail window enables developers to examine what caused an exception.
Edit and Continue
The Edit and Continue features enable you to fix bad code and resume the application execution from the point where it was broken, without having to restart the application. You just need to run the application by pressing F5; then you can break its execution by pressing Ctrl+Alt+Break or either selecting the Break All command in the Debug menu or pressing Pause on the Debug toolbar.
In our example we need to fix the code that searches for a not existing file. We can replace the line of code with this one:
Dim getSomeText As String = "Fixed code"
This replaces the search of a file with a text message. At this point we can press F5 (or F11 if we want to just execute the line of code and debug the next one) to resume the execution. Figure 2.34 shows how the application now runs correctly. The Edit and Continue feature completes the overview of the debugging features in Visual Studio. As we mentioned before, this topic is covered in detail in Chapter 6.
)
Figure 2.34. The sample application running correctly after fixing errors.
After this brief overview of the debugging features in Visual Studio 2012, it’s time to talk about another important topic for letting you feel at home within the Visual Studio 2012 IDE when developing applications: getting help and documentation.