The tool that you'll use for structured exception handling is the Try - Catch - Finally structure. This structure has been used in the C family of languages for decades and has proven its worth so it's simply been adopted by Visual Basic in .NET. The name suggests the syntax:
Try
<Code where the exception might be raised>
Catch <except var> as <except object>
<Code to handle the exception>
Finally
<Code to execute in any case>
End Try
There are some variations on this syntax. You can catch different kinds of exceptions in the same structure:
Try
Catch e1 as excep1
<code>
Catch e2 as excep2
<code>
End Try
And you can conditionally catch exceptions:
Catch e as <except> when <condition>
The complete rules are available at MSDN or in the Visual Basic Help system.
The illustration below shows an example of the entire structure in code. Note that a specific exception (OverflowException) is being tested for. To to maximum extent possible, you should try to anticipate the problems that can occur and code exception handling specifically for those exceptions.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
The "Stack" and Multi-Level Error Handling
If no Catch block is coded to handle the exception, the "stack" is "unwound" to the calling method. This language (Which is a little foreign to Visual Basic but very familiar to C++ programmers. We couldn't do things like this before .NET.) refers to the way the .NET CLR - the Common Language Runtime - keeps track of program calls to sub programs in a memory "stack". Stacks are a type of collection that was discussed in a previous segment of this tutorial.
When the stack is unwound, control is transferred to the calling program and doesn't return. This gives you sophisticated multi-level capability to handle some exceptions right in the program code where they were caught and others in higher level routines.
You can create your own exception objects and Throw your own exceptions. You can also "rethrow" exceptions that are passed to one of your Catch blocks. Although it would be possible to create exception coding for all kinds of things, Microsoft recommends that you use ordinary conditional statements errors that happen routinely. For example:
If Password_Not_Long_Enough Then Display_Retry_Dialog
When you start coding your own exception objects, there are a lot of new considerations to pay attention to. For example, there are two exception namespaces. One for system generated exceptions and one for your application. Just as in other types of programming, nothing is off limits and you could inherit and modify Microsoft's exception objects if there was a good reason, but Microsoft recommends that any exception objects you create should be inherited from the ApplicationException class. Your exception object should implement polymorphism by having at least three New constructor methods.
Public Class myUniqueException
Inherits ApplicationException
Public Sub New()
<your exception code>
End Sub
Public Sub New(ByVal message As String)
MyBase.New(message)
<your exception code>
End Sub
Public Sub New(ByVal message As String, ByVal inner As Exception)
MyBase.New(message, inner)
<your exception code>
End Sub
End Class
Your code could create the property values for the exception object. And you may need to implement your own event handling code for exceptions. In short, there's a lot to be done when you choose the approach of creating and throwing your own exceptions.
To wrap up this discussion of exception handling, I've included an example of exception processing in the downloadable code. This example is a standard form that calls a method in an instance of a class: ExceptionTestClass. To demonstrate how exceptions are unwound from the stack, the method calls another Sub which actually contains the Try - Catch - Finally structure. The Try block calls yet another Sub which throws a system exception. Since this Sub doesn't have any exception processing, the stack is unwound to the calling Sub where the exception is caught. The Finally block is executed next and control returns to the main form. MessageBox calls show exactly how control is passed as demonstrated by the illustration below:
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
Explaining how it's done and doing it are two different things. So on the next page, we demonstrate error handling in the Signature Block program.

