-
Jul 12th, 2018, 07:05 PM
#1
Thread Starter
Member
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
-
Jul 13th, 2018, 03:06 AM
#2
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>
-
Jul 13th, 2018, 07:18 AM
#3
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.
-
Jul 13th, 2018, 03:50 PM
#4
Thread Starter
Member
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.
.
-
Jul 13th, 2018, 04:01 PM
#5
Thread Starter
Member
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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|