VB6 error propagation

Question

Hi, I'm using an error handler on my main calling procedure and letting the other procedures just roll up to that error handler.

Should I be clearing the error each time? Or should I Exit Sub instead of letting the error handler continue on the End Sub?

I'm asking because I've read that I may catch the first error, and then the other errors won't be handled.

Sorry if this is less than clear. Not really sure what I'm saying.

Thanks!!

Edit: Something like this. Is this necessary?

Public Sub SubA()
On Error Goto ProcError

  ' other code  
  MsgBox FuncA()

ProcExit:  
  Exit Sub

ProcError:  
  MsgBox Err.Description  
  Resume ProcExit
End Sub

Answer 1

OP: Should I be clearing the error each time? Or should I Exit Sub instead of letting the error handler continue on the End Sub?

What do you mean by clearing the Error?
Usually, the procedure is written in this manner

public sub myProcedure()
on error goto e:
'statements that could raise error
exit sub

e:
Log err.Number, err.Description, "error occurred in myProcedure"
end sub

OR

You could choose not to add the error handler. In which case, the error will be propagated to the caller (or the procedure where it is handled).

Please post the sample code of what you are trying to achieve & your expectation.

EDIT: Here is what the code posted by you means

Public Sub SubA()
On Error Goto ProcError

  ' other code  
  MsgBox FuncA()
exit sub   'put exit sub otherwise it will execute the line below, even if no error

ProcExit:  
'this statement will get executed after the error msgbox is shown
msgbox "Reached ProcExit"
Exit Sub

ProcError:  
MsgBox Err.Description  'catch the error and show the msgbox
'error is cleared the point it reaches ProcError
'Resume ProcExit acts as goto, to execute any statements after the error is handled
Resume ProcExit 
End Sub

Answer 2

With your particular example, you do not need to clear the errors out because your pattern is based on catching errors. Though it does not hurt:

ProcExit:  
  Exit Sub

ProcError:  
  MsgBox Err.Description  
  Err.Clear
  Resume ProcExit

Now, if you had a pattern where you checking for errors instead of catching them, then yes, you'd have to clear it. Here is small example:

On Error Resume Next
Dim o as Object

Set o = myCollection(someKey)

if Err.Number <> 0 then
   ... respond to error
   Err.Clear

I hope this helps.

Answer 3

The Err object is cleared whenever you exit a Sub as expected (e.g., no error occurs). In your example, the Resume ProcExit statement is unnecessary. The following two subs behave the same way:

Public Sub SubA()
  On Error Goto ProcError
  MsgBox FuncA()
ProcExit:  
  Exit Sub
ProcError:  
  MsgBox Err.Description  
  Resume ProcExit
End Sub

Public Sub SubA()
  On Error Goto ProcError
  MsgBox FuncA()
  Exit Sub
ProcError:  
  MsgBox Err.Description  
End Sub

You don't have to use the Exit Sub statement to clear the Err object. Simply falling out of the sub when you hit End Sub has the same affect.

If you want errors from "the other procedures" to "roll up" (a better word is propagate) to the error handler on your main calling procedure, they shouldn't contain error handlers at all. For instance, suppose Main calls SubA, and SubA calls FuncA. An error occurs in FuncA. If you handle the error in FuncA by simply displaying a message box, like you do in your example, the code is going to continue executing in SubA, but will be in an unstable state because something went wrong in FuncA and SubA does not know about it.

One option is to refrain from putting error handlers in SubA and FuncA. When an error happens in FuncA, it gets raised to SubA, which in turn raises it to Main where it is then properly handled.

An even better option is to trap the errors, log them, then re-raise them. Then when the error finally gets to your Main Sub with the error handler, you'll have more information to work with.