On Error Statement 15

[SharonAnaki]

hi,

Is there any connection between On Error and the functioning of the compailer?
or -
what happens when VB meets an On Error Statement?

sharon

 

[NeilBarnard]

when VB comes across an error in a procedure/function in which you have put in error handling code, it basically does what you have code it to do. If you had not put in any error handling code, VB/Windows will display its own error numbers and messages, which in most cases are very mis-leading and not to the point as far as the context is concerned.
Neil

 

[SharonAnaki]

hi Neil,
i thank you for your replay, but i think that my question was not clear enough. i am trying to understand what happens to the computer when it "meets" an error and what does the statement do to "undo" it.
yours,
sharon

 

[edderic]

The question is not clear !

You have : On Error GotO 0 or Err.Clear or On Error Resume Next

What is you question ?
Eric De Decker
vbg.be@vbgroup.nl

Licence And Copy Protection AxtiveX.
Download Demo version on my Site:

http://www.createsoftware2000.com

 

[RickSpr]

I think perhaps I understand your question. The On Error statement doesn't itself "undo" an error. It just tells VB to remember what to do if an error occurs later on in the program's execution.

First, let me describe an Error Context. This is a group of private variables in VB's own space; it's not available to your code. It contains the following:
- ErrorAction: A code that specifies which kind of
On Error statement was most recently executed.
- ErrorLabel: If the ErrorHandling code indicates that
an On Error Goto <label> statement was executed,
the label that was specified in the statement.
- ErrorHandlerActive: A true/false variable used
internally to prevent infinite loops. I'll explain
this more later.
- ErrorLoc: A pointer (sort of like a statement
line number) that indicates where an error
occurred, if any.

When an On Error statement executes, it stores a code in the ErrorHandling variable about which kind of On Error statement it is, either On Error Resume Next, On Error Goto 0, or On Error Goto <label>. In the case of Goto <label>, it also stores the label name in ErrorLabel. That's all the On Error statement does, is store this information. The stored information remains in effect until another On Error statement is executed.

Later on, the VB runtime code may detect an error, such as an invalid argument to a function or a type conversion error. The first thing the VB runtime does is save information about the error (the error number, description, source, and help file reference) in its ErrObject object. Next it checks its ErrorHandlerActive flag. If the flag is on, the runtime invokes VB's Default Error Handler. (I'll say more about the Default Error Handler later.) Otherwise, ErrorAction is inspected to determine which kind of On Error statement was most recently executed:
- If it was an On Error Resume Next, VB moves to the next statement and resumes execution.
- If it was On Error Goto <label>, VB stores the location of the statement where the error occurred in ErrorLoc, turns on the ErrorHandlerActive flag, and resumes execution at the label given in ErrorLabel.
- If it was On Error Goto 0, the runtime invokes the Default Error Handler.

Let me explain about ErrorHandlerActive flag now. Suppose an error occurs after an On Error Goto <label> has executed. VB will continue execution at the specified label. But suppose another error occurs in a statement after that label? If VB again resumed execution at the specified label, it would get into a loop that might never end. To prevent that, VB uses ErrorHandlerActive to &quot;remember&quot; that it's already processing an error when it transfers to the error handler, and refuses to resume at the label again. If another error occurs while ErrorHandlerActive is on, VB transfers to the Default Error Handler instead. That prevents the loop from happening.

How, then, does the ErrorHandlerActive flag get turned off? By executing a Resume (or Resume Next or Resume <label>) statement. You have to execute one of these before VB will consider your error handling routine finished.

The difference between Resume, Resume Next, and Resume <label> is this: Resume returns execution to the statement identified by ErrorLoc in the Error Context (in other words, it retries the same statement that originally caused the error). Resume Next returns execution to the statement that follows the one in ErrorLoc. Resume <label> ignores ErrorLoc altogether, and transfers execution to the specified label.

There's something I didn't tell you about the Error Context: Each active procedure has its own. If you've ever used the Call List during debugging, the Error Context is part of that. Each Error Context contains all the error handling specifications for its own procedure. When execution enters a procedure (via an event, or via a procedure, method, or function call in another procedure), VB creates an Error Context for the new procedure and initializes it as if an On Error Goto 0 statement had been executed. (Thus, by default, errors will go to the Default Error Handler.) When a procedure exits, its Error Context is discarded at the same time the procedure is removed from the Call List.

Now you're ready to understand the Default Error Handler. If an error invokes the Default Error Handler, VB checks the Error Context for the procedure that called it. If that Error Context has ErrorHandlingActive set to true, or if it has On Error Goto 0 in effect, then VB checks the Error Context from the procedure that called it, etc. VB keeps &quot;bubbling up&quot; the error through the Call List in this way until it either runs out of calling procedures or finds a procedure that has On Error Resume Next or On Error Goto <label> in effect. If it runs out of calling procedures, VB displays the error to you in a message box.

If it finds an Error Context that has On Error Resume Next or On Error Goto <label> in effect, VB terminates all the subprocedures that it had &quot;bubbled up&quot; through, and then acts as if the error had occurred on the current statement of the procedure to which this Error Context belongs. That current statement, of course, is the one that called the next procedure down. (Note: VB does not change the contents of the ErrObject object; ErrObject still reflects the information from the original error.)

What this all comes down to is that, if you want to trap errors in a procedure, or catch &quot;bubbled&quot; errors from procedures it calls, you should write your code like this:

    Sub Foobar()
        . On Error Goto 0 is in effect at start of
        . procedure. If an error occurs here, it will
        . "bubble up".
        On Error Goto ErrorHandler
        .
        . (if code here causes any error, VB will invoke
        .  ErrorHandler)
        .
        On Error Resume Next
        .
        . (if code here causes any error, VB will ignore
        .  it and continue to next statement. ErrObject
        .  will contain details of the error.)
        .
    ErrorExit:
        Exit Sub  ' keeps us from continuing into ErrorHandler

    ErrorHandler:
        Select Case Err.Number
            Case nnn (something you can ignore)
                Resume Next
            Case nnn (something you can fix)
                (do something to fix it)
                Resume ' try same statement again
            Case nnn (something else you can fix)
                (do something to fix it)
                Resume ErrorExit ' skip rest of procedure
        End Select
        ' Couldn't fix or ignore the error - the 
        ' following statement will "bubble" it up
        Err.Raise Err.Number
    End Sub

Don't be discouraged if you found all this hard to follow. It is! Fully developed error handling is very complicated, and takes cautious planning. But I hope I've been able to shed some light on it for you. Rick Sprague

 

[happyabc]

Excellent article - 2 years old so I thought I'd bubble it up for the benefit of the site freshmen.