- Sub Procedures
- Creating Functions
- Using Optional Arguments
- Passing a Variable Number of Arguments
- Preserving Data Between Procedure Calls
- Understanding Scope
- Handling Runtime Errors
- Unstructured Exception Handling
- Structured Exception Handling
- Introducing Classes and Objects
- Summary
- Q&A
- Workshop
Unstructured Exception Handling
In Visual Basic, unstructured exception handling revolves around the On Error GoTo statement. Here's how the On Error GoTo statement works:
On Error
{ GoTo [ line | 0 | -1 ] | Resume Next }
The parts of this statement are as follows:
GoTo lineCalls the error-handling code that starts at the line specified at line. Here, line is a line label or a line number. If a runtime error occurs, program execution goes to the given location. The specified line must be in the same procedure as the On Error statement.
GoTo 0Disables the enabled error handler in the current procedure.
GoTo -1Same as GoTo 0.
Resume NextSpecifies that when an exception occurs, execution skips over the statement that caused the problem and goes to the statement immediately following. Execution continues from that point.
The following example shows how to use the On Error GoTo statement that uses division by zero to create an overflow error. In this case, the code redirects execution to the label Handler. You can create this label by placing it on a line of its own followed by a colon:
Module Module1 Sub Main() On Error GoTo Handler . . . Exit Sub Handler: End Sub End Module
Note that we've used an Exit Sub statement here so that in normal execution, the procedure stops before reaching the error-handling code that follows the Handler label. Now we can add the code that causes the overflow error:
Module Module1 Sub Main() On Error GoTo Handler Dim intItem1 As Integer = 0 Dim intItem2 As Integer = 128 Dim intResult As Integer intResult = intItem2 / intItem1 Console.WriteLine("Press Enter to continue...") Console.ReadLine() Exit Sub Handler: End Sub End Module
When the overflow error occurs, control is transferred to the Handler label, and we can add code there to display an error message to the user, as shown in Listing 3.6 and the OnError project in the code for this book.
Listing 3.6 Using Unstructured Exception Handling (OnError project, Module1.vb)
Module Module1 Sub Main() On Error GoTo Handler Dim intItem1 As Integer = 0 Dim intItem2 As Integer = 128 Dim intResult As Integer intResult = intItem2 / intItem1 Console.WriteLine("Press Enter to continue...") Console.ReadLine() Exit Sub Handler: Console.WriteLine("An overflow error occurred.") Console.WriteLine("Press Enter to continue...") Console.ReadLine() End Sub End Module
Now when you run this code, you'll see this result:
An overflow error occurred. Press Enter to continue...
In this way, you were able to handle the exception without having Visual Basic display all kinds of error message boxes.
Here's something else to know: If you call procedure B from procedure A, and B doesn't have any On Error exception-handling code but A does, then if an exception occurs in B, control will transfer back to A, where the exception will be handled.
Getting an Exception's Number and Description
A built-in error object named Err has a Number property that enables you to determine an error's number. While testing your program, you can use Err.Number to determine the numbers of the errors you might run into and can then use those numbers to handle those errors in different ways. For example, this code handles only overflow errors, which are error number 6:
Module Module1 Sub Main() On Error GoTo Handler Dim intItem1 As Integer = 0 Dim intItem2 As Integer = 128 Dim intResult As Integer intResult = intItem2 / intItem1 Console.WriteLine("Press Enter to continue...") Console.ReadLine() Exit Sub Handler: If (Err.Number = 6) Then Console.WriteLine("An overflow error occurred.") End If Console.WriteLine("Press Enter to continue...") Console.ReadLine() End Sub End Module
TIP
As of this writing, the Visual Basic documentation no longer includes a list of errors by error number. To find a runtime error's number, you can always create that error yourself and have your code display the value of Err.Number.
You can also use the Err object's Description property to get a short description of the error, as in this code:
Module Module1 Sub Main() On Error GoTo Handler Dim intItem1 As Integer = 0 Dim intItem2 As Integer = 128 Dim intResult As Integer intResult = intItem2 / intItem1 Console.WriteLine("Press Enter to continue...") Console.ReadLine() Exit Sub Handler: Console.WriteLine(Err.Description) Console.WriteLine("Press Enter to continue...") Console.ReadLine() End Sub End Module
This code displays this message:
Arithmetic operation resulted in an overflow. Press Enter to continue...
TIP
You can determine more details about the source of an error by using the Err object's Source property. This property holds the name of the object or application that caused the error. For example, if you connect your program to Microsoft Excel and it generates an error, Err.Source will hold "Excel.Application".
Using Exception Objects
You can also use Err.GetException to get an exception object that enables you to determine what kind of runtime error occurred. Visual Basic .NET has many exception objects, and you can see a sampling in Table 3.1.
Table 3.1 Some Visual Basic Exceptions
AppDomainUnloadedException |
ArgumentException |
ArgumentException |
ArgumentNullException |
ArgumentOutOfRangeException |
ArithmeticException |
ArrayTypeMismatchException |
BadImageFormatException |
CannotUnloadAppDomainException |
ComponentException |
DivideByZeroException |
DllNotFoundException |
DuplicateWaitObjectException |
EntryPointNotFoundException |
ExecutionEngineException |
ExternalException |
FieldAccessException |
FormatException |
IndexOutofRangeException |
InvalidCastException |
InvalidOperationException |
InvalidProgramException |
MissingFieldException |
MissingMemberException |
MissingMethodException |
MulticastNotSupportedException |
NotFiniteNumberException |
NotImplementedException |
NotSupportedException |
NullReferenceException |
ObjectDisposedException |
OperationException |
OutOfMemoryException |
OverflowException |
PlatformNotSupportedException |
RankException |
SafeArrayTypeMismatchException |
StackOverflowException |
TypeInitializationException |
TypeLoadException |
TypeUnloadedException |
UnauthorizedAccessException |
UriFormatException |
|
For example, to test for an overflow error, you can check if the type of the exception is OverflowException. To do that, you use the TypeOf and Is keywords, which are specifically designed for just this purpose to be used in If statements to work with objects:
Module Module1 Sub Main() On Error GoTo Handler Dim intItem1 As Integer = 0 Dim intItem2 As Integer = 128 Dim intResult As Integer intResult = intItem2 / intItem1 Console.WriteLine("Press Enter to continue...") Console.ReadLine() Exit Sub Handler: If (TypeOf Err.GetException() Is OverflowException) Then Console.WriteLine("An overflow error occurred.") End If Console.WriteLine("Press Enter to continue...") Console.ReadLine() End Sub End Module
If the type of exception that occurred is OverflowException, the message "An overflow error occurred." will be displayed here.
Even though structured exception handling is newer than unstructured exception handling, you can still do things with unstructured exception handling that you can't with structured exception handling. The main thing is that you can resume execution of the part of your code that caused the error (after skipping the problematic line) using the Resume statement.
Using the Resume Statement
After an exception occurs, you can use the Resume statement to resume program execution in unstructured exception handling. Here are the possibilities:
Resume resumes execution with the statement that caused the error.
Resume Next resumes execution with the statement after the one that caused the error.
Resume line resumes execution at line, a line number or label that specifies where to resume execution.
Listing 3.7 is an example using Resume Next; this is the Resume project in the code for this book. It enables you to skip over the line that caused the problem and keep going with the following line.
Listing 3.7 Using the Resume Statement (Resume project, Module1.vb)
Module Module1 Sub Main() On Error GoTo Handler Dim intItem1 As Integer = 0 Dim intItem2 As Integer = 128 Dim intResult As Integer intResult = intItem2 / intItem1 Console.WriteLine("Press Enter to continue...") Console.ReadLine() Exit Sub Handler: Console.WriteLine("An overflow error occurred.") Resume Next End Sub End Module
Here's what you see when you run this application:
An overflow error occurred. Press Enter to continue...
And here's an example using Resume line to do exactly the same thing. Here, we're using a line label, LineAfter, which is just a (nonreserved) word followed by a colon that can be used to label a line of code:
Module Module1 Sub Main() On Error GoTo Handler Dim intItem1 As Integer = 0 Dim intItem2 As Integer = 128 Dim intResult As Integer intResult = intItem2 / intItem1 LineAfter: Console.WriteLine("Press Enter to continue...") Console.ReadLine() Exit Sub Handler: Console.WriteLine("An overflow error occurred.") Resume LineAfter End Sub End Module
TIP
You can use the statement On Error Resume Next or On Error Resume at the beginning of your code when you don't want to add explicit exception-handling code. These statements will make Visual Basic .NET continue execution after an exception has occurred.
Turning Off Exception Handling
To turn off unstructured error handling, you can use the On Error GoTo 0 or On Error GoTo -1 statements (they do the same thing). Here's an example:
Module Module1 Sub Main() On Error GoTo Handler Dim intItem1 As Integer = 0 Dim intItem2 As Integer = 128 Dim intResult As Integer intResult = intItem2 / intItem1 On Error GoTo 0 Console.WriteLine("Press Enter to continue...") Console.ReadLine() Exit Sub Handler: Console.WriteLine("An overflow error occurred.") Resume Next End Sub End Module
Now that we have a good understanding of unstructured exception handling, we'll look at structured exception handling next.