Error Handling - pass some err's to one level up caller

I have two procedures, MAster & SLave, where MA call SL. Both of them has their own Error Handlers. However it's needs to pass some err's from SL to MA unhandled (or "as unhandled"). "Some" means here - manually raised err's. I.e. all custom err's, manually raised in SL, are subject to be passed to MA and to be handled there. But native MS err's must to be handled locally in SL.

I found the only way - to raise the same err again in SL in its handler. But it seems me clumsy...

Maybe there are other, more elegant solutions?
.

Code:

---

Private Const ERAMGC = (45200 + vbObjectError)
'
Private Sub sb_ErrTest_MA() ' Master
Dim j&
Dim sErrDsc$
On Error GoTo ErH
   
    For j = 1001 To 1003
        Call sb_ErrTest_SL(j)
    Next
   
ErE:
    Exit Sub
ErH:
    With Err
        sErrDsc = .Description
        Select Case .HelpContext
            Case ERAMGC ' it is user raised err
                Debug.Print sErrDsc
                Stop
            Case Else
                sErrDsc = .Number & "_" & sErrDsc
                Debug.Print sErrDsc
                Stop
        End Select
    End With
    Resume ErE
End Sub

Private Sub sb_ErrTest_SL(pVal&) ' Slave
Dim lDbz&
Dim sErrDsc$
On Error GoTo ErH

    Select Case pVal
        Case 1001: ' OK - do nothing
        Case 1002: lDbz = pVal \ 0&
        Case 1003: Call sb_ErrRaise(pVal)
        Case Else: Stop
    End Select
   
ErE:
    Exit Sub
ErH:
    With Err
        sErrDsc = .Description
        Select Case .HelpContext
            Case ERAMGC ' it is user raised err
                Debug.Print sErrDsc
                Stop
                ' Here I need to pass this err unhandled ..
                ' .. to caller's err handler on uplevel procedure
                Call sb_ErrRaise(pVal)
                Resume ErE
            Case Else
                sErrDsc = "MS Err " & .Number & " - " & sErrDsc
                Debug.Print sErrDsc
                Stop
                ' Here I need to maintain this err localy
                Resume Next
        End Select
    End With
End Sub

Private Sub sb_ErrRaise(pVal&)
Dim lNmb&
Dim sDsc$
    lNmb = pVal + vbObjectError
    sDsc = "ERA_" & CStr(pVal)    'HelpContext para used to pass Magic number by it ..
    Call Err.Raise(lNmb, , sDsc, , ERAMGC) ' .. to quicly dif raised err's from MS's
End Sub

---

Try switching local err handler off in sb_ErrTest_SL before calling sb_ErrRaise like this

| On Error GoTo 0
| Call sb_ErrRaise(pVal)

This way local error handler would not have to deal with Case ERAMGC ' it is user raised err

Generally using error handling for control of flow is not very good idea. The same way as exception handling in C++/C#/Java is not recommended for control of flow. Better recommended is to just use Boolean retval for success/failure and output param for Error details. E.g. MS combined both of these in HRESULT and generally every big system reinvents HRESULT for handling alternative control of flow (success case is regular case, failure is the alternative control of flow).

I personally treat raised errors as unhandled ones, i.e. errors that the application did not expect to happen, that should be logged at least and/or presented to the user do decide if the app state is already garbage and app should restart it immediately or not.

Then based on these collected logs I'm either silencing each particular error (e.g. a big switch in the error handler or OERM before the offending line) or eliminating the root cause of it (e.g. if division by zero take care the param never gets zero value). Rinse & repeat and in couple of years expect convergence to empty logs :-))

cheers,
</wqw>

@asbo - wqweto described best practice, so I really have nothing to add except that - yes it seems awkward, but what you've illustrated is typical / normal. It's usually farmed out to a ReThrow()/ReRaise() type of procedure that kicks the exception back to the caller. It's ugly - but at least looks cleaner than Err.Raise within the Handler.

wqweto,
thank you for reply.

* On Error GoTo 0
- Yeah... I tried it and it's worked.
But it gives some of inconveniences:
- this statements will be randomly scattered throughout the code
- and I do not like that they are phisically & logically associated with the error raiser, but not with error handler.

However, my twiced "raise-after-raise" is not better, but m.b. the worse, taking into account that the another Err-object raised under of current one, which is not finished else.

In the rest, thanks for sharing your practical experience. It keeps me moving in the right direction.

Earlier we already touched on this matter here. However, at this stage I just forced to use handlers, although I'm moving to returning of the error flag ("just use Boolean retval for success/failure" as you say) with its next expanded interpretation on the caller.
.

DEXWERX,
thank you for confirming wqweto view and on support of my doubts :)
.