Using Unstructured Exception Handling

As discussed in the In Depth section of this chapter, there are now two ways of handling runtime errors in Visual Basic—you can use structured or unstructured exception handling (exceptions are runtime errors). Unstructured exception handling revolves around the On Error GoTo statement, and structured exception handling uses the Try…Catch…Finally statement. Without an On Error GoTo or Try…Catch…Finally statement, any exception that occurs is fatal and your program will stop.

I'll take a look at the On Error GoTo statement first in this and the next few topics. Although one gets the impression that Microsoft would far rather you use Try…Catch…Finally, there are simply some things you can do with On Error GoTo that you can't do with Try…Catch…Finally, such as resume execution with a Resume statement.

The On Error GoTo statement enables exception handling and specifies the location of the exception-handling code within a procedure. Here's how the On Error GoTo statement works:

On Error { GoTo [ line | 0 | -1 ] | Resume Next }

Here are the parts of this statement:

• GoTo line—Enables the exception-handling code that starts at the line specified in the required line argument. The line argument is any line label or line number. If an exception occurs, program execution goes to the given location. (Note that the specified line must be in the same procedure as the On Error statement.)

• GoTo 0—Disables enabled exception handler in the current procedure and resets it to Nothing.

• GoTo -1—Same as GoTo 0.

• Resume Next—Specifies 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.

Here's an example showing how to use the On Error GoTo statement that uses a division by zero to create an overflow exception. In this case, I'm directing execution to the label "Handler", which you create by placing this label on a line of its own, followed by a colon—note that I also place an Exit Sub statement before the exception handler so the exception-handling code isn't executed inadvertently during normal program execution:

Module Module1
    Sub Main()
        Dim int1 = 0, int2 = 1, int3 As Integer
        On Error Goto Handler
        int3 = int2 / int1
        Exit Sub
Handler:
        ⋮
    End Sub
End Module

And I can add exception-handling code in the exception handler like this:

Module Module1
    Sub Main()
        Dim int1 = 0, int2 = 1, int3 As Integer
        On Error Goto Handler
        int3 = int2 / int1
        Exit Sub
Handler:
        System.Console.WriteLine("Overflow error!")
    End Sub
End Module

Now when this console application runs, you'll see "Overflow error!". You can also handle specific exceptions in different ways depending which exception occurred by checking the Err object's Number property, which holds the exception's number. Here, I'm handling only arithmetic overflow exceptions, which are exception number 6:

Module Module1
    Sub Main()
        Dim int1 = 0, int2 = 1, int3 As Integer
        On Error Goto Handler
        int3 = int2 / int1
        Exit Sub
Handler:
        If (Err.Number = 6) Then
            System.Console.WriteLine("Overflow error!")
        End If
    End Sub
End Module

The Err object also has a new GetException method that returns an exception object. For more on these objects, see the topic "Using Structured Exception Handling" in this chapter. Using the TypeOf and Is keywords in an If statement, you can handle exception objects such as OverflowException like this:

Module Module1
    Sub Main()
        Dim int1 = 0, int2 = 1, int3 As Integer
        On Error Goto Handler
        int3 = int2 / int1
        Exit Sub
Handler:
        If (TypeOf Err.GetException() Is OverflowException) Then
            System.Console.WriteLine("Overflow error!")
        End If
    End Sub
End Module

Now that structured exception handling has been added to Visual Basic, the real attraction of unstructured exception handling is the Resume statement—see the next topic.