Structured error handling will be a completely new concept to Visual Basic and VBScript developers. Since the .NET Framework requires the use of Strong Typed Languages, such as Visual Basic it is time to learn how to use this method of error handling.

Background

Up until ASP.NET only unstructured error handling has been available within a web page, as with prior versions of Visual Basic. For those of you who are not aware what unstructured error handling is please see Listing 1.1 for a list and description of each argument. In Visual Basic, unstructured error handling starts with the On Error Statement.

Listing 1.1

1. On Error GoTo Line or Field - When an error occurs with in the scope of this handler the execution of code jumps to the Line number or field specified in the On Error statement .
2. On Error Resume Next - When an error occurs the execution of code halts and goes to the statement immediately following the one where the error occurred.
3. On Error GoTo 0 - Disables all error handlers within the procedure where it resides, resetting them to nothing.
4. On Error GoTo -1 - Disables any enabled exceptions within the procedure where it resides, resetting them to nothing.

Structured Error Handling

You are still allowed to use the unstructured error handlers in ASP.NET, but why? ASP.NET and VB.NET introduce structured error handling, which is borrowed from VC++. Structured error handling comes in following form, see Listing 1.2

Listing 1.2

Try    Try Code Catch ex As Exception [Filters]    Catch Code Finally    Finally Code End Try

The Catch statement can be used to catch general exceptions or specific exceptions, and allows for multiple Catch statements within the same try block. For an example see Code Block 1.1

Let's walk through what happens when Code Block 1.1 is executed. First we declare a new object named MyObject, and call it's fictitious method named CallMethod, because this method does not exist an exception is thrown and Line 4 is never executed. The compiler checks the Catch Statements, first checking for a specific handler for that exception, which we have on Line5.

Note: If we didn't have that catch statement, the DefaultExcep handler would be used, you can test this by taking out Lines 5-6 of the Try block.

Now that we caught the exception in Line 5, we can do something; (recover or tell the user an error has occurred), we tell user that an error has occurred. After all statements in the Catch block are executed the Finally statements contents are executed and we end the Try block. The executed page can be seen in Figure 1.1

You can use custom error messages like I have done, or you can use .NET's built in error messages. You can use the variable we assign the exception object to, in our case NRE,

NRE As NullReferenceException

And do things such as,

Response.Write(NRE.Message)

Which will give us the famous, Object variable or With block variable not set, error message. Or you can do nothing, just catch it and move on.

The exception object created has some very useful properties you can use in development and testing to help minimize errors. One such property is StackTrace, which will give you a stack trace as a string which will help to determine where the error occurred. Another is TargetSite, which indicates the method that threw the exception. Source, is the name of the application or object that generated the error. The ToString method, you can retrieve the name of this exception, the error message, the name of the inner exception, and the stack trace.

Things to remember:

1. You do not need to use the Finally block
2. You can have multiple Catch blocks in one Try...Catch...Finally statement
3. You can get valuable information from the Exception object created
4. Structured error handling is more robust than unstructured error handling

I hope you can see how valuable using the Try...Catch...Finally block can be and how big of step it is from the On Error GoTo statement. Now instead of just redirecting to a new page if you receive an error, you can actually write code to handle that error, and possible recover from it. Imagine if you will you have a form on one of your pages that you use to allow people sign up to be a member on your site, typically you insert this data into a database, but for whatever reason your SQL Server box is down, now instead of giving the person an error message that they can't sign up right now and to try later, you can log that persons information into a log file, or email it to the system administrator for later insertion and let the person sign up to be a member without error.