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:
 Syntax, Runtime, and Logic Errors
 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:

 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,
 And then observe the effects.
 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
 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:
 Watch the values of variables.
 Watch the values of expressions.
 Use the QuickWatch Dialog to change the code, during Break Mode:
 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.

 The first item is ‘Me’, which is the current Form, itself.
 You may expand items to view other variables and values, as desired.
 Similar to the Watch Window, you may change variable values…
values
 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 :
 File Input / Output Errors
 Hard-disk access, loss of connection error, etc
 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:
 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
 Example: An Input/Output Error (As System.Exception.IOException).
 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
 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>”