Naming of error handling routine

[twgonder]

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

So, now I'm really confused, often not knowing if one is talking about a sub or function. In any case, is this post all wet?


https://www.accessforums.net/showthr...236#post498236

[twgonder]

This topic, for me anyways, quickly got out of hand. I just don’t have enough experience with errors and VBA yet to know the best way to handle errors. And there is quite a bit of disagreement between the experts. For other newbies that may be in the same boat, here is my temporary solution.

While developing, I’ll add a generic error handler to all subs and functions. Later it can be easily removed if deemed not necessary in EVERY procedure as the bubble-up advocates suggest. First, I need to understand what kinds of errors there are and how best to handle each one. To do that, I can comment out the On Error GoTo line in the offending procedure to focus in on the exact offending line of code and fix it.

One universal unanticipated error handler (for now, all errors are unanticipated) will msgbox display all. Once I understand better, the Select Case statements can be uncommented and coded.

Public Function ErrUnhandled(lngErr As Long, strError As String, strSubFunc As String) As Boolean
    MsgBox "Unanticipated error in procedure: " & strSubFunc & vbCrLf & lngErr & ": " & strError
    ErrUnhandled = True
End Function

Public Function FcnTest2()
    Dim Test As Single, MyError As Boolean
    On Error GoTo ErrCd

    Test = 3 / 0
    
ExitCd:
    Exit Function

ErrCd:
'    Select Case Err
'    Case 998, 999: command
'    Case Else
       MyError = ErrUnhandled(Err, error, "FcnTest2")
'    End Select
    Stop
    Resume ExitCd
End Function

[CJ_London]

You can find lists of error codes on line, but not aware of any that group them by 'topic'
for example
https://fmsinc.com/MicrosoftAccess/E...scription.html

think your ErrUnhandled needs to do a bit more. As a developer you may come across unhandled errors and fix them so as a developer tool, OK. But when your app goes to production, the expectation is that the function will never be called. However if it is called, you don't want to drop the user into the VBE (you can't anyway if the app is .accde). And you need to decide whether the error can be ignored so the user can carry on, or is fatal to the app and the only option is to close the app.

You may also want the function to log the error in a log table and/or email the developer with the details

[Micron]

So, now I'm really confused, often not knowing if one is talking about a sub or function. In any case, is this post all wet?
https://www.accessforums.net/showthr...236#post498236

I was hoping for an explanation of how a sub can return a value if that's what you mean, because M$ documentation does not support that contention. If the meaning was to set a module level variable according to the code in a sub, then to me that is setting a variable value that is exposed to the calling code and is not the same as returning a value to a line statement in that code.

Can you point out where the disagreement is if you were referring to something else? I'd like to review.
Thanks.

[CJ_London]

I was hoping for an explanation of how a sub can return a value if that's what you mean, because M$ documentation does not support that contention

the post in the link is trying to explain that you can assign a value to a byRef parameter. Applies to both subs and functions. But only functions can return a value that is assigned outside of the function. There are plenty of API's that do this - ones I use regularly would be using the RECT and POINTAPI types as parameters


sub mysub(x as integer)

function myfunction(x as integer)

with code

x=10

will both assign the value of x to the variable passed as a parameter.

Personally I rarely use subs since functions can do the same thing and more - such as being referenced in queries, called by ribbons and assigned to events.

[Micron]

So is it fair to say that a sub isn't really returning a value to the statement in the calling procedure - it's altering the value of a variable that was declared ByRef (which by definition, is a pointer to a space in memory)? All I can say is that the M$ documentation states that a sub cannot return a value to a calling procedure and that is what I've long believed. I think that is what twgonder is questioning, but not sure.