Lecture 8 - Debugging_errorhandling_midterm (vb 2008)

Midterm Test Announcement 

Our Midterm Test will be Next Class 

The main part will be on Wednesday, July 9, First Period.

However, the test is actually in 2 parts: Part 1 - Check of the Base Project (Today) 

We already did this together.

Part 2 - In-class RAD Assignment (next Wednesday)  



Where I ask you to extent the project in Class. You will submit your project folder by the end of Class.

Now, open the DialogBox Task, which we did in class… 

And were using to demonstrate VB.NET Debugging.

Lecture 8: Debugging (continued) and Error Handling

Introduction 

As developers, part of our job is to find, remove, and handle errors… 

Such errors generally fall into 3 major categories: 





Finding and removing logic errors (bugs) is called Debugging.

Last lecture, we discussed each of these error types, 

along with powerful debugging tools provided by our .NET IDE :  



Setting Breakpoints The Breakpoints Window

Now, we continue by looking at more debugging tools: 



Syntax, Runtime, and Logic Errors

The Command, Watch, and Locals Windows

Followed by a discussion of Runtime Errors and Error Handling 

Using the Try…Catch…Finally block

.NET Debugging Windows 

VB Studio provides various Debugging Windows… 

Each helps us monitor code behavior during run-time.



We have already seen the Breakpoints Window… 



Useful for setting, and monitoring behavior at Breakpoints.

Four more Debugging Windows are also available/useful:    

The Immediate Window The Autos Window The Watch and Locals Windows Note: Most can be accessed from Menu, or the Debug Toolbar :

The Immediate Window 

Let’s start by discussing the Immediate Window : 

This allows you to control a run, directly … 



For help in debugging.

Using the Immediate Window, we may monitor and / or set running conditions:  

Query for (ask about) the values of variables. Intervene with the run, and set the values of variables, 



Intervene by inserting small amounts of code to alter program execution: 



e.g., closing objects or changing values.

However, you may only enter code while execution is paused 



And then observe the effects.

i.e., you must be in Break Mode.

Let’s try it out, by running our Debug Project one more time…

Ex: Using the Immediate Window

Skipping Statements (Example)

The Watch Window 

Another helpful Tool is the Watch Window 

Using this debugging tool, you may: 

Monitor program execution during run-time:  



Use the QuickWatch Dialog to change the code, during Break Mode:   



Watch the values of variables. Watch the values of expressions. Add new variables Add new expressions. Again, this function is only possible after halting at a Breakpoint.

Let’s try it out, by running our Debug Project again…

Ex: Using the Watch Window

The Locals Window 

Another useful tool for debugging is the Locals Window : 

It automatically shows all Variables for the current Procedure/Function: 





As these exist and contain values (thus, ‘Locals’)

And also shows all existing Objects, as well.

The Locals Window for our Debug Project is shown below:



As shown, objects and User-defined variables are displayed automatically.  



Similar to the Watch Window, you may change variable values… values  



The first item is ‘Me’, which is the current Form, itself. You may expand items to view other variables and values, as desired. But only while execution is paused (Break Mode) As usual, text for variables/objects with changed values turns red.

So experiment with this Window, yourself!

Error Handling 

In addition to debuggable errors, run-time errors may also occur. 

Due to unexpected system behaviors while running. 

Typical examples :  





In each case, an error-specific Exception will be Thrown…

The Common Language Runtime responds to such errors, automatically.  

Usual: Program Termination + an ‘Unhandled Exception’ message... Except during debugging, this behavior is not user-friendly:  



File Input / Output Errors Hard-disk access, loss of connection error, etc

No information about the error type . No possibility of user recovery (program terminates).

All .NET languages provide Structured Error-Handling : 

Via Blocks of code designed to ‘Catch’ expected Exceptions... 



When Thrown by the System.

The block will then ‘Try’ to deal with the error in a graceful manner. 

Examples:  



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

In VB.NET, error-handling is handed by ‘Try…Catch…Finally’ Blocks.

The ‘Try…Catch…Finally’ Structure 

The ‘Try…Catch…Finally’ structure consists of 3 Blocks:  Try : 



Tries an exception-prone portion of code;

Catch : 

Handles a specific type of anticipated error 



A filter can also be provided for conditional halting  



This is just a Boolean (True / False) statement after the Exception Type. You must use the When keyword + condition (e.g., When y=0)

Several Catch blocks can be provided to Catch different Exceptions 



Example: An Input/Output Error (As System.Exception.IOException).

It is wise to try to handle all expected types of non-debuggable errors.

Finally (optional): 

(Always) executes a desired block of clean-up code.  

Whether or not an Exception is Thrown. However, if desired, this may be skipped with an Exit Try statement…  Placed at the end of the Catch Block.

Example: Error Handling

Example (cont.)

Midterm Test Announcement / Check 

Our Midterm Test will be Next Class 

The main part will be on Wednesday, July 9, First Period.

However, the test is actually in 2 parts: Part 1 - Check of the Base Project (Today) 

We already did this together.

Part 2 - In-class RAD Assignment (Tuesday)  



Where I ask you to extend the project in Class. You will submit your project folder by the end of Class, Tuesday.

Now: open the DialogBox Task, which we did in class. 

Save a test file, with the sentence: 

“In Class Verification for <MyName, MyStudentID>”