Unless you code error-handling routines in every procedure you write, Visual
Basic needs a way of finding that error handler when a runtime error occurs. This section discusses
the methods by which Visual Basic finds that error-handling procedure and what happens if
one is not found.
Developers of Visual Basic programs control error handling with the On Error statement.
The On Error statement dictates how a runtime error will be handled when encountered. If a
procedure in your code is executing and an error occurs, Visual Basic looks for On Error within
that procedure. If the On Error statement is found, the commands following On Error are executed.
If an error handling does not exist in the procedure in which the error occurred, Visual Basic goes
up in the calling chain to the code that called the current procedure to look for an On Error
statement. Visual Basic continues going up the calling chain until some kind of error handling
is found. If there is no procedure in the calling chain with error handling, the application ends
with a fatal error.
The following example shows how errors will be handled in a simple code example:
Private Sub Main()
Call SubroutineA
End Sub
Private Sub SubroutineA()
Call SubroutineB
End Sub
Private Sub SubroutineB()
Dim I as Integer
Dim J as Integer
I = 0
J = 10 / I
End Sub
If you have these three procedures in your application, you can see that this code
will generate a runtime error in SubroutineB. The statement J = 10 / I will generate a "divide
by zero" error. When this application runs, sub-routine Main starts, and then it calls
SubroutineA, which in turn calls SubroutineB. After the runtime error occurs in SubroutineB,
Visual Basic must determine how to handle the error.
In this case, when the error occurs in SubroutineB, Visual Basic looks in SubroutineB
for error handling specified by an On Error statement. Because it is not coded,
Visual Basic goes up the calling chain to SubroutineA and checks there for error
handling. Again because none is found, Visual Basic goes up the chain to Main.
Because Main does not have any error handling either, a fatal error occurs and
the application shuts down.
Now consider the case where sub-routine Main is modified to look like this:
Private Sub Main()
On Error GoTo Main_Error
Call SubroutineA
Exit Sub
Main_Error:
Msgbox "An error occurred."
Resume Next
End Sub
When this code runs, a division by 0 still occurs in SubroutineB. Visual Basic
still checks for error handling in SubroutineB and then in SubroutineA. When it
is not found, Visual Basic checks Main for an On Error statement. This time it
finds one and does whatever the errorhandling statement instructs. In this case
there is a statement instructing that execution continue at the label Main_Error.
A message box is displayed, and then a Resume Next statement is encountered.
You must be aware of the point that a Resume Next or a Resume statement will
send you to after the error occurs. A Resume Next statement will not send you
back into SubroutineB to the statement after the divide by 0. It sends you instead
to the statement in Sub Main after the line that made the call to the procedure
that generated the error. In this case the Exit Sub statement would be executed
next.
It is important to remember two important things about the errorhandling hierarchy.
The first is that Visual Basic will search up the procedure in the calling chain
until an error handler is found. As an example look at a case where there are
three procedures in the calling chain: ProcA, ProcB, and ProcC. ProcA calls ProcB,
which in turn calls ProcC. If an error occurs in ProcC, Visual Basic will look
in that procedure for an error handler. If one is not found, Visual Basic will
go up the calling chain to ProcB and look for an error handler there.
Again if one is not found, Visual Basic will check ProcA. The second thing
to remember is that if there is no error handler in the calling chain, a fatal
error occurs and the application shuts down.
