Results 1 to 5 of 5

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

  1. #1

    Thread Starter
    Member
    Join Date
    Mar 2018
    Posts
    35

    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

  2. #2
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

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

    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>

  3. #3
    PowerPoster
    Join Date
    Jun 2015
    Posts
    2,224

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

    @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.

  4. #4

    Thread Starter
    Member
    Join Date
    Mar 2018
    Posts
    35

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

    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.
    .

  5. #5

    Thread Starter
    Member
    Join Date
    Mar 2018
    Posts
    35

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

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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width