Lecture 7: Errors and Debugging
As developers, part of our job is to find and remove errors…
Such errors generally fall into 3 major categories:
Finding errors is called Debugging.
Syntax Errors Runtime Errors Logic Errors (also called bugs) This job can be quite difficult.
In lecture 7, we discuss these error types…
And introduce some powerful debugging tools provided by our .NET IDE :
Setting Breakpoints The Breakpoint Window
Occur when the programmer uses incorrect VB.NET syntax.
As a result, the Compiler cannot understand the statement.
Typical examples :
This is the simplest and most common type of error. mis-spelling a declared variable, or VB .NET keyword trying to use an undeclared variable (see Example, below). providing incorrect parameters in a Method Call, etc
The VB .NET IDE helps us spot and fix syntax errors: 1. The error is underlined in blue. (see Example below) 2. Placing the cursor over the error causes a ToolTip to appear…
Which (usually) clearly explains the problem.
Here, we have mistakenly used the Private Keyword to declare a local variable.
Syntax Errors (Auto-Correct) 3. Visual Studio.NET 2008 provides an AutoCorrection option :
A convenient Drop-Down Dialog which suggests corrections
Click to view Intellisense’s suggestions, if any for correcting the error. Along with a preview of the corrected code.
If you like, you may select one of the suggestions (just click the blue text)
(here, we may correct by clicking “Replace ‘Private’ with ‘Dim’ ”
This ‘IntelliSense’ feature provided by the IDE… Also provides features to help prevent (not just correct) Syntax Errors. 1. A drop-down menu to help recall Members/Methods of Classes, etc.
This occurs when the dot operator (.) is used… Just select the Name from the Menu, and press Tab or Enter.
Here, my example shows the Methods of Class ‘File’…
As shown by Intellisense, the Method, File.OpenText(path as String) …
makes and passes a StreamReader Object to read the file at ‘path’ Thus, it is equivalent to the StreamReader() constructor we looked at in class.
This helps you to remember the available Members / Methods for a Class.
IntelliSense also provides help in calling Methods: 2. A Tool-Tip Parameter list for called Methods…
Which appears when you type the parentheses for a Method call. Listed information includes:
Parameter Number and Types, and Return Type General description of parameters A Drop Down list of selectable choices for the parameter (not all may be valid…)
This helps remember and set the parameters for available Methods. Note: For overloaded Methods, the menu lists available Method versions…
Allowing you to choose which Method version to use.
Runtime errors occur during Program Execution…
Due to unexpected behavior while running…
Typical examples :
Hard-disk error Loss of connection error (Internet) Database or Server Error, etc
The .NET platform provides Error-Handling Blocks for Developers…
Developers may use these to ‘Catch’ expected Errors...
And then ‘Try’ to deal with them in a more graceful manner. Such a set of Error-Handlers is called an Error-Handling ‘Logic’.
Causing the Program to Fail during operation; Providing the user with little explanation or choice.
Bypass the portion of code that failed. Allow the user to retry the failed operation (write, connection, etc.)
We will discuss Runtime Errors in the next Lecture (Error Handling).
For now, we will focus on Debuggable Errors.
The Exception Assistant
As shown below, VB Studio 2008 provides an Exception Assistant…
To assist us in handling errors that occur during run-time (= “Exceptions”).
For instance, the code below contains an error…
Here, the String, strData has not been initialized.
In VB 2008, Strings are required to be assigned a value…
Before the actual String object is created in memory…
So, strData is just an empty object reference to a non-existent object (String).
Thus, when we run this code, and Button1 is pushed:
And handed back to the named object reference (here, strData)
Our code will attempt to reference the Text of a non-existent String; A Null Reference Exception (error) will be ‘thrown’
Let’s take a look…
The Exception Assistant (cont.)
As shown, our code runs to the line containing the error (yellow):
And halts upon occurrence of an ‘unhandled’ exception.
However, instead of crashing, we are provided with help: An Exception Assistant Dialog Box.
This Dialog Box provides information about the exception:
Type of exception (here, a NullReferenceException). Troubleshooting tips, to help us fix the error in the code. Specific details about the exception. (click ‘View Detail’ to see details…)
Here, we have ( 日本語 ): ‘Object reference not set to an instance of the object’,
Occur when the developer does not fully understand his code.
In this case, the program may yield incorrect results or behavior…
Typical examples :
Even though all of the Syntax is correct (Hard to Spot!). An Infinite Loop (a loop that never stops looping; see example below) Improper Branching (e.g., incorrect If-Then logic) A comparison operation which does not yield the expected result.
The .NET platform provides good Debugging Tools for Developers… 1. A Debug ToolBar for access to these Debugging Tools 2. The ability to set and use Breakpoints…
A place in code where program execution is set to halt. Either automatically or conditionally.
3. Several Debugging Windows to monitor code behavior during Runtime:
The Breakpoint Window The Command Window The Watch and Locals Windows
Example: Debugging Demo
Let’s use our TextEditor Project to demonstrate Debugging…
Debugging Demo (cont.)
It is common to need to debug a project at a particular place in code…
For such cases it is useful to set a Breakpoint:
This allows us to run normally up to our ‘point of interest’ and then stop...
A place in code where execution is set to halt automatically.
So we may step through the code (line-by-line) from there, to find the error.
Breakpoints are usually added while writing code…
But can also be added while a running program is waiting for user input.
Note: Debugging tools are available with the Build Configuration set to Debug
…But not Release.
When a breakpoint is encountered:
Execution will stop automatically (default), or conditionally (if set)…
A condition for halting may be set using the Breakpoints Window. This halted state is referred to as ‘Break Mode’.
Program execution will stop at the line just before the breakpoint.
(actually, at the very beginning of the breakpoint line…)
From here, we will generally step through the code using the Debug ToolBar.
Breakpoint Ex (Setting Breakpoints)
The Breakpoints Window
Using the Toolbar Debugging Icons
Several useful icons are available on the Standard Toolbar…
The Step Into Icon:
Allows you to step through your code line-by-line…
The Step Over Icon:
Allows you to step through a Function or Subroutine in 1 step
Note: The code still executes.
The Step Out Icon:
Allows you to step to the end of the current Function/Subroutine in 1 step.
Beginning from the current line.
Note: Code still executes
The Run To Cursor Icon:
Allows you to set the cursor anywhere after the current line…
And then execute all code up to that point.
To add this icon:
Right-click an empty area on the Toolbar; Choose ‘Customize’ in the Context Menu In the Customize Dialog: Choose Commands > Debug Drag ‘Run To Cursor’ onto the Toolbar.
Using ‘Step Into’ and ‘Step Out’
Using the Breakpoint Hit Count •
Let’s continue working with our Debug Project…
Breakpoint Hit Count (cont.)
Using a Breakpoint Condition
This lecture, we discussed program errors…
Syntax, Logic, and Runtime Errors
We also learned to use some .NET debugging tools for catching bugs:
Setting Breakpoints The Breakpoints Window
Next lecture, we continue our with some additional debugging tools:
And focused on Syntax and Logic Errors (bugs)
The Command and Autos Windows The Watch Window The Locals Window
Followed by a discussion of Run-time errors and Error Handling
Using the Try…Catch…Finally structure.