1. Visual Basic

The following discussion is a summary of error trapping techniques in Visual Basic. For more detailed information, please refer to the Visual Basic online documentation under "Error Trapping."

When errors are encountered executing code, or accessing components, Visual Basic sets a global object, Err, with information regarding the error. This object has fields for an error number, a description, a help file and help context, and a LastDLLError. Once the error is set, Visual Basic "raises" the error so an application can process it. If no code is written to explicitly handle the error, the Visual Basic runtime will display the error description in a Message box and when this is acknowledged, exit the program.

Generally Visual Basic programs will use the error handling functions discussed below in conjunction with a global error object, which stores extended error information. Programs use the properties of this object to obtain the details of the error for decision making or display.

To handle errors in your Visual Basic code and avoid the default message and exit behavior you add On Error statements to your code. There are 3 flavors of this statement.

On Error GoTo indicates a label within the current subroutine where execution begins when an error is detected. For routines that are unlikely to receive errors or have no good recourse when an error is encountered, a good practice is to use this statement at the beginning of a routine directing all errors to an error handler at the bottom of the routine. Just before the error handler an Exit Sub statement causes normal execution paths to leave the routine. After the label, standard code can be inserted to print the error to the screen, write info to a log file, send e-mail or whatever is appropriate.

Sub MySubroutine

On Error GoTo MyHandler

Dim srv as Server 

set srv = Servers.Item("no-such-server") 

msgbox srv.name 

Exit Sub

MyHandler:

MsgBox Err.Description & VBCrLf & Hex(Err. Number) 

End Sub

The error handler does not need to exit the routine. Instead, it can resume execution within the routine at a named label, at the statement that detected the error, or at the statement following the one that detected the error. In order to do this; you must use the Resume statement. Never use a GoTo statement to branch from an error handler into the main body of the routine. If you do so, and another error occurs, that error will not be trapped. Instead, you will get an error dialog and your program will terminate.

On Error Resume Next is used for in-line error trapping. After this is called in a routine, the Visual Basic runtime will continue to set the global error object when problems are encountered, but except for that, the error will be ignored and execution resumes on the next line of code. You can check for errors by testing the Err object's Number property (its default property). If there were no errors, Err.Number will be zero. If an error occurs, Err.Number will be nonzero and it remains nonzero until it is cleared. The Err object is cleared explicitly by calling Err.Clear, or it is cleared implicitly by an On Error statement.

You can test Err.Number for specific errors using an If or Select Case statement. After handling an error, you should clear the error object.

Sub MySubroutine

On Error Resume Next

mysrv.Open("uid=no-such-user")

If Err Then

If Err.Number = pseACCESSDENIED Then 

MsgBox "The user and/or password you provided is incorrect." & _ 

" Try again." 

Err.Clear 

GoTo RetryLogic 

Else 

Err.Raise 'Unexpected error, let our caller handle it

End If 

End If

...

On Error GoTo 0 is used to cancel the effects of earlier On Error statements in a routine and return to the default situation where Visual Basic catches the errors, displays a message and aborts.

In general a program will use the error handling method appropriate to the situation at hand. Longer routines will often switch between different error handling methods depending on the types of errors they expect to receive and their ability to act on an error return. Errors may also be propagated up a call stack by raising any errors that cannot be handled locally, as in the example.

Enabling Operational Intelligence