Unstructured error handling has been a part of Visual Basic since it first debuted in the early 1990s. It's simple to use, catches all possible errors in a block of code, and can be enabled or disabled as needed. By default, methods and property procedures include no error handling at all, so you must add error-handling codeunstructured or structuredto every routine where you feel it is needed.
The idea behind unstructured error handling is pretty basic. You simply add a line in your code that says, "If any errors occur at all, temporarily jump down to this other section of my procedure where I have special code to deal with it." This "other section" is called the error handler.
Public Sub ErrorProneRoutine() ' ----- Any code you put here, before enabling the ' error handler, should be pretty resistent to ' run-time errors. ' ----- Turn on the error handler. On Error GoTo ErrorHandler ' ----- More code here with the risk of run-time errors. ' When all logic is complete, exit the routine. Return ErrorHandler: ' ----- When an error occurs, the code temporarily jumps ' down here, where you can deal with it. When you're ' finished, call this statement: Resume ' ----- which will jump back to the code that caused ' the error. The "Resume" statement has a few ' variations available. If you don't want to go ' back to main code, but just want to get out of ' this routine as quickly as possible, call: Return End Sub
The On Error statement enables or disables error handling in the routine. When an error occurs, Visual Basic places the details of that error in a global Err object. This object stores the numeric error code, a text description of the error, related online help details, and other error-specific values. I'll list the details a little later.
You can include as many On Error statements in your code as you want, and each one could direct errant code to a different label. You could have one error handler for network errors, one for file errors, one for calculation errors, and so on. Or, you could have one big error handler that uses If...Then...Else statements to examine the error condition stored in the global Err object.
ErrorHandler: If (Err.Number = 5) Then ' ----- Handle error-code-5 issues here.
Specific error numbers for common errors can be found in the online documentation for Visual Studio, but it is this dependence on hard-coded numbers that makes unstructured error handling less popular today than it was before .NET. Still, you are under no obligation to treat errors differently based on the type of error. As long as you can recover from error conditions reliably, it doesn't always matter what the cause of the error was. Many times, if I have enabled error handling where it's not the end of the world if the procedure reaches the end in an error-free matter, I simply report the error details to the user, and skip the errant line.
Public Sub DoSomeWork() On Error GoTo ErrorHandler ' ----- Logic code goes here. Return ErrorHandler: MsgBox("An error occurred in 'DoTheWork':" & _ Err.Description) Resume Next End Sub
This block of code reports the error, and then uses the Resume Next statement (a variation of the standard Resume statement) to return to the code line immediately following the one that caused the error. Another option uses Resume some_other_label, which returns control to some specific named area of the code.
Disabling Error Handling
Using On Error GoTo enables a specific error handler. Although you can use another On Error GoTo statement to redirect errors to another error handler in your procedure, a maximum of one error handler can be in effect at any moment. Once you have enabled an error handler, it stays in effect until the procedure ends, you redirect errors to another handler, or you specifically turn off error handling in the routine. To take this last route, issue the following statement:
On Error GoTo 0
Your error handler doesn't have to do anything special. Consider this error-handling block.
ErrorHandler: Resume Next
When an error occurs, this handler immediately returns control to the line just following the one that generated the error. Visual Basic includes a shortcut for this action.
On Error Resume Next
By issuing the On Error Resume Next statement, all errors will populate the Err object (as is done for all errors, no matter how they are handled), and then skip the line generating the error. The user will not be informed of the error, and will continue to use the application in an ignorance-is-bliss stupor.