21
Lecture 7: Errors and Debugging

Lecture 7 - Debugging and Break Mode (VB 2010)

Embed Size (px)

DESCRIPTION

Application Lecture

Citation preview

Lecture 7: Errors and Debugging

Introduction

As developers, part of our job is to find and remove errors… Such errors generally fall into 3 major categories:

Syntax Errors Runtime Errors Logic Errors (also called bugs)

Finding errors is called Debugging. 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

Syntax Errors Occur when the programmer uses incorrect VB.NET syntax.

As a result, the Compiler cannot understand the statement. This is the simplest and most common type of error.

Typical examples : mis-spelling a declared variable, or VB .NET keyword trying to use an undeclared variable. providing incorrect parameters in a Method Call, etc

The Visual Studio 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 2010 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’ ”

IntelliSense 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 (cont.) 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 us 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 Runtime errors occur during Program Execution…

Due to unexpected behavior while running… Causing the Program to Fail during operation; Providing the user with little explanation or choice.

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 blocks to ‘Catch’ anticipated Errors...

Then deal with them in a more graceful manner. Such a set of Error-Handlers is called an Error-Handling ‘Logic’.

Examples: Bypass the portion of code that failed. Allow the user to retry the failed operation (write, connection, etc.)

Runtime Errors and Error Handling will be covered in the next Lecture. In this lecture, our main focus will be on Debuggable Errors. However, first we quickly discuss the ‘Exception Assistant’

The Exception Assistant In Debug Mode, Visual Studio 2010 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 2010, Strings are required to be assigned a value… Before the actual String object is created in memory…

And handed back to the named object reference (here, strData) So, strData is just an empty object reference to a non-existent object

(String).

Thus, when we run this code, and Button1 is pushed:1. Our code will build (compile) with no error (this is not a syntax error).2. During the run, a reference will be made to the Text of a non-existent String;3. A Null Reference Exception (error) will then 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 just crashing, we are also 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’, etc.

Logic Errors Occur when the developer does not fully understand his code.

In this case, the program may yield incorrect results or behavior… Even though all of the Syntax is correct (Can be Hard to Spot!).

Typical examples : 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.)

Setting Breakpoints 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:

A place in code where execution is set to halt automatically.

This allows us to run normally up to our ‘point of interest’ and then stop... 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…

Beginning from the current 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.

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, select ToolBar > Debug

Then click ‘Add Command’: Choose Categories > Debug Select ‘Run To Cursor’ and click OK.

It will appear on 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

Forward…

This lecture, we discussed program errors… Syntax, Logic, and Runtime Errors

And focused on Syntax and Logic Errors (bugs)

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: 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.