Naming of error handling routine

[twgonder]

I'm plowing through lots of sample code for ideas and best practices.

This is one that I have a question about, and I see something similar in a lot of examples:

Private Sub Form_Open(Cancel As Integer)
On Error GoTo Form_Open_Err
formtran Me
Form_Open_Exit:
   Exit Sub
Form_Open_Err:
   MsgBox Err.Description & " in Form_Open"
   Resume Form_Open_Exit
End Sub

Notice the name for the error routine, "Form_Open_Err". Quite long and maybe meaningless.
Either it was created automatically, or someone took a lot of time to name every error routine after the name of the procedure.
I question if that is necessary. Would something more generic be less ideal?

Private Sub Form_Open(Cancel As Integer)
On Error GoTo SubErr
formtran Me


SubExit:
   Exit Sub
SubErr:
   MsgBox Err.Description & " in Form_Open"
   Resume SubExit
End Sub

Is there a valid reason to NOT user the labels as I did in orange for all procedures in a module? (I think that's what they call subs and functions.)

Even more valuable, why not call another subroutine to handle all errors? That way one set of code could display the same 'ol message box and maybe even log the error programmatically (and we could eliminate all that duplicate code in every procedure). Since in a error subroutine, we wouldn't need the SubExit:, would we just do a "Resume" to get back to the calling procedure that had the error? How do we just exit the calling sub with the error (if we use the subroutine model) so more undesired code doesn't run? Is there a variable the error subroutine could use to know the calling sub that had the error?



Or, does every procedure need a a duplicated error and exit section , and if we want to use a different subroutine for the msgbox, just add that to the SubErr: code?

Since the sub is private and contained, I can't see any problem with the code getting confused by the same label names, and it takes less bytes, and maybe the compiled version is more efficient/smaller without all the different label names?

Am I missing something?

[Micron]

You can't stop code with called code - the upstream procedure (the parent in the call stack) must either run to completion or until it hits an exit line. Even if you cancel an event such as form opening by using its cancel property, it will continue to the End Sub line if not halted otherwise. As for a universal handler, not all errors are handled in the same way. Some require an exit, some a prompt, some resume after the handled error, some resume next after the handled error, and so on. About all you can do universally IMO is to invoke a standard message box or custom message form. Re the name - converting macros to code is often responsible for such verbiage. I simply write

On Error GoTo errHandler
 more code

exitHere:
clean up
Exit Sub

errHandler:
IF's or SELECT CASE block might be here, or maybe just
Msgbox "Error " & Err.Number & ": " & Err.Description
Resume exitHere

AFAIC, any time you set object variables or mess with application settings you must have an error handler to ensure settings are restored and objects are terminated. I doubt that opinion is shared by everyone though. Not sure if I addressed all your points.

[twgonder]

You can't stop code with called code .... As for a universal handler, not all errors are handled in the same way. Some require an exit, some a prompt, some resume after the handled error, some resume next after the handled error, and so on.

AFAIC, any time you set object variables or mess with application settings you must have an error handler to ensure settings are restored and objects are terminated. I doubt that opinion is shared by everyone though. Not sure if I addressed all your points.

Got it, now I imagine there are a fairly common set of errors that that can be trapped. Things like drive not ready, network down, etc.
I don't see anything that allows for Call routine (GoSub{or Call} not GoTo) (but I will have to try it I suppose and see if it works). Then if the error isn't handled in any of the standard ways , the called subroutine could pass back a variable indicating failure (or success if it was handled okay). Still, there remains the problem of getting your code to continue where you want without resorting to a lot of Goto(s).

Does this make sense in VBA?

[CJ_London]

Even more valuable, why not call another subroutine to handle all errors?

commonly done for unhandled errors.

function unhandled(errcode as long, errdesc as string, subfunc as string) as boolean

    msgbox "there is an unhandled error in " & subfunc & vbcrlf & errcode & ":- " & errdesc
    unhandled=true 'you might want to do more which results in a false

end if

and called from code

errHandler:
   select case err
     case 123:
       'do something
     case 345:
       'do something else
     case else
        unhandled err, err.description,"name of sub or function"
    end select

[twgonder]

commonly done for unhandled errors.

That makes a lot of sense.

When I started with a Business BASIC forty years ago, I got a lot of run-time errors. There wasn't an error trap within that BASIC, you just fell into a runtime debugger and could fix a variable (not code, because it had to be compiled) continue running or just kill the process (and be diligent in the implication to data). And then go fix the code so the error wouldn't happen again. After the first year of shaking out a big application, it could run (as of now, thirty) for years without ever seeing a run-time error again. I suppose it's different with PCs (compared to a mini/mainframe). I'm curious, in reality how often do you as a developer see errors after testing? How often do users report "strange" errors to you? I have no clue being new (again) to VBA and Access.

[twgonder]

commonly done for unhandled errors.

function unhandled(errcode as long, errdesc as string, subfunc as string) as boolean

...

errHandler:
   select case err
     case 123:
       'do something
     case 345:
       'do something else
     case else
        unhandled err, err.description,"name of sub or function"
    end select

Are there some system variables that we can pass to unhandled that has the procedure name and line number (I know there aren't explicit line numbers) for showing and logging where the error occurred? That way we don't have to hard code it and the detail is more helpful in knowing exactly where the error was.

[CJ_London]

THat question has been asked before. It involves interrogating the stack. Can’t remember what the conclusion was but since I haven’t adopted it, pretty sure it was more trouble than it was worth. Try Googling something like ‘vba get sub name from stack’ or similar.

[Micron]

I don't see anything that allows for Call routine

Not sure what you mean by that. Call is a key word that will direct flow to another procedure and is required in some cases but most often, simply typing the name of the called procedure is enough to run it. I'd say it's generally considered bad form to use GoTo to direct flow based on variable values or other conditions/properties such as

If strIn = strOut Then GoTo lineLabel1

[CJ_London]

I'd say it's generally considered bad form to use GoTo to direct flow

totally agree. Call is a throwback to the old basic syntax and although some still use it, it has no benefit that I am aware of.

[twgonder]

Not sure what you mean by that. Call is a key word that will direct flow to another procedure and is required in some cases but most often, simply typing the name of the called procedure is enough to run it. I'd say it's generally considered bad form to use GoTo to direct flow based on variable values or other conditions/properties such as

If strIn = strOut Then GoTo lineLabel1

Well, it seems MS wants to use Goto, at least in their error handling. When I said call, it was meant generically to mean instead of
On Error GoTo label:
we could use
On error GoSub (or Call) procedure

MS VBA and other "structured languages" can use fancy terms like Exit, Resume, Resume Next and Resume line, but they are also just GoTo in disguise when you get to the bottom of the issue.

[isladogs]

Are there some system variables that we can pass to unhandled that has the procedure name and line number (I know there aren't explicit line numbers) for showing and logging where the error occurred? That way we don't have to hard code it and the detail is more helpful in knowing exactly where the error was.

It would indeed be a very useful feature and is one that I spent a lot of time looking into over the years.
Some years ago, I came up with a solution for this involving the Microsoft Visual Basic for Applications Extensibility 5.3 library and used it in one of my commercial apps as part of an error logging feature.

This was the code I used:

Private Sub YourEventName()


On Error GoTo Err_Handler


   ...code here
    
Exit_Handler:
    Exit Sub
    
Err_Handler:
    strProc = Application.VBE.ActiveCodePane.CodeModule.ProcOfLine(Application.VBE.ActiveCodePane.TopLine, 0)
    MsgBox "Error " & Err & " in line " & erl & " of procedure " & strProc & " :  " & vbCrLf & Err.Description
    Resume Exit_Handler


End Sub

Although it often works, it isn't anything like 100% reliable and I (like most other developers) have decided that it just isn't possible to do using VBA

FWIW:
1. I use generic error handling in all procedures including entering the procedure name
2. Using line numbering as part of error handling (courtesy of MZ Tools0 is very useful when fixing complex issues with code errors
3. I NEVER use Call in my code

[davegri]

Here's my 2 cents worth:

Call Fixup(nKey)
is exactly the same functionality as
Fixup nkey
Both of these have implicit Returns to the following line of code

GoSub AddAll
is not a call to a procedure, it is an execution transfer to a line label (ending with a colon such as Addall: in this case) in the same procedure
Gosubs require an explicit Return command in their execution path that will return execution to the line after the Gosub

GoTo Skipit transters execution to a line label (Skipit: ) in the current procedure and does not require a Return



Note that Gosub and Goto must always be embedded in the current procedure. They can direct execution to code before or after themselves in the procedure.

I like to use Call because I can instantly determine the purpose of that line of code.

[CJ_London]

On error GoSub (or Call) procedure

not tested to see if that might work but that presumes you have one basic routine to handle all errors - and in real life that is just not the case, as already stated, fine for all unhandled errors - basically ones you as a developer have not anticipated, but sometimes you need them handling - anything from adding a record or instantiating a variable to correcting a spelling. Some you can handle in code 'if s=""' some you can by resuming and correcting after the error, some you cannot avoid generating an error - for example a common one for me is parent - if parent exists then 'me' is in a subform control. Alternative would be to scan through all open forms, and scan through their controls looking for subforms, then check the subform control for the name of the form to see if it matches. Which is OK until you have two subform controls using the same form.

[Micron]

Call Fixup(nKey)
is exactly the same functionality as
Fixup nkey

Maybe. Maybe not. Documentation states that the return value of a function is discarded if you use the Call statement. I don't know how you'd use the Call statement in a way that you'd expect to handle the return value of a function that was called - mainly because I never use Call, I guess. Call seems like an outdated statement to me.

[davegri]

Maybe. Maybe not. Documentation states that the return value of a function is discarded if you use the Call statement. I don't know how you'd use the Call statement in a way that you'd expect to handle the return value of a function that was called - mainly because I never use Call, I guess. Call seems like an outdated statement to me.

Either way the return is discarded, because a function called that way is treated like a sub, which has no return value.
If you want to use a function's return value you do like this:

Rslt = fcnGetIt
or
If fcnGetIt = "OK" then...