Search Down atm - Error Handling Code

JMongi

Active member
Local time
Today, 04:46
Joined
Jan 6, 2021
Messages
802
Normally I'd crawl the forums using the search function but it's MIA at the moment. I had some error code I copied from somewhere else and while I understand what it's doing, I'd like to make some informed decisions on the type and complexity of my error handling. Any forum threads you have bookmarked or other references I can peruse? Thanks!
 
put the error trap in your procedure:
Code:
sub MySub()
on error goto errTrap
   'normal code here
exit sub   'exit normal code so as not to run into the error trap

errTrap:
msgbox err.description, ,err
end sub
 
+1 for the simplicity and effectiveness of what ranman posted, I do the same structure 90% of the time
 
Normally I'd crawl the forums using the search function but it's MIA at the moment. I had some error code I copied from somewhere else and while I understand what it's doing, I'd like to make some informed decisions on the type and complexity of my error handling. Any forum threads you have bookmarked or other references I can peruse? Thanks!
Appears to be working now?

However before moving to the new software, I used to use this method.

https://time.com/9922/quick-tech-tr...add “site:time.,Text Shortcuts for Your Phone
 
+1 for the simplicity and effectiveness of what ranman posted, I do the same structure 90% of the time
So, in this code I see no resuming of execution. If that is the plan, how is that different than Access error handling?
 
So, in this code I see no resuming of execution. If that is the plan, how is that different than Access error handling?
Exactly. I have "argued" a bit about this before with others (lol), but to make a long story short, I see virtually no reason to "resume" anything if you intend for your error handler to be the end of the road. I almost never use a resume. Why have a "resume" line that does nothing but Exit Sub, if the line immediately after your error handler is End Sub anyway??

Any unhandled error will cause a Runtime application to crash "execution of this app has stopped and must be shut down" , in my experience - so there's plenty of value in simply handling an error just to handle the error
 
Well, I know where I stand on this issue ;)
I like to explicitly do things as opposed to implicitly, especially if the net amount of work is negligible.
That being said, my real question is about this statement:
if you intend for your error handler to be the end of the road.
Is this the preferred ending for an error for the end user? I guess I need to think about what I would want a user to do if there was an error.
 
As an aside...it appears the "similar threads" filter is working still which gives me some additional reading options!
 
Well, I know where I stand on this issue ;)
I like to explicitly do things as opposed to implicitly, especially if the net amount of work is negligible.
That being said, my real question is about this statement:

Is this the preferred ending for an error for the end user? I guess I need to think about what I would want a user to do if there was an error.
Well yeah, it certainly all depends on your intent. if you have more complex error handling, and actually want to trap errors in an error block and then resume a separate part of the code.

FWIW, I don't see anything implicit in the fact that the next line is "End Sub". That explicitly ends the sub, IMHO

But I am with you in explicit-ness, even if it's just a teency bit redundant. That's why I don't usually rely on Default Properties of things. (i.e., I like to put .Value, it keeps my mind engaged with what property I am or am not referring to)
 
I'm not quite following this construction:
msgbox err.description, ,err
So, this would display the internal access error description in a message box. What is the second "err"? Is that a messagebox type? I didin't see that anywhere in my messagebox reading.
 
Ok. I'm back. I haven't had a chance to fully test this code (other than compiling) but I'm close. Here is the current code:
Code:
Function FormNullChk(FormName As String) As Boolean
'This function is used as a basic check to make sure all data entry controls have values.
'Tag all form controls that need validated with tag "validate"
'Function returns "True" if no nulls and "False" if nulls.
'Null Control Captions are added to a user messagebox.

On Error GoTo ErrHandler

Dim Ctl As Control
Dim NullCtl As String

FormNullChk = True
NullCtl = " "
For Each Ctl In Forms(FormName).Controls
    If Ctl.Tag = "validate" Then
        If IsNull(Ctl.Value) Then
            NullCtl = NullCtl & Ctl.Name
            FormNullChk = False
        End If
    End If
Next Ctl

If FormNullChk = False Then
    MsgBox ("Please enter the values for" & NullCtl & "before saving."), vbInformation
End If

ErrHandler:
Call ErrProcessor
FormNullChk = False 'I don't want to save a record if there is an error.
Exit Function
    
End Function
Here is my error handler sub:
Code:
Public Sub ErrProcessor()
'Developer mode = Yes results in descriptive errors and no logging
'Developer mode = No results in generic error message and error logging

If StandardFunctions.DeveloperMode = True Then
    MsgBox Err.Description, vbExclamation, "Program Error"
Else
    MsgBox "There was an unexpected error.  Please contact your administrator.", vbExclamation, "Program Error"
    'ErrorLog - capture user, form, error, error description, date and time
End If
End Sub

So my question has to do with this line of code:
Code:
NullCtl = NullCtl & Ctl.Name
My control names wouldn't necessarily be clear to the end user. For example, one of my control names is "TaskIDFK". Is there another property to use for this line of code? What do you use when a label isn't available?
 
I use the controls datasheet caption and set it to some sensible descriptive text. A bit more work but very much more user-friendly.
Add it to your loop something like

ctl.Properties("DatasheetCaption") & vbCrLf

This adds a line feed as well for readability.
If you returned the msg text as a string result of the function you could make the message more form specific.
Simple test at the form end of things

If len(FormNullChk & "") > 0 then ' I have a message to display
 
Last edited:
Maybe a silly question, but do you end up using spaces in your datasheet captions?
 
Maybe a silly question, but do you end up using spaces in your datasheet captions?
Yes - they are only there for display purposes - I never (well hardly ever) use datasheets as a display medium but even if I did, they are only there for "prettiness" and readability for the end user.
 
For example, one of my control names is "TaskIDFK". Is there another property to use for this line of code? What do you use when a label isn't available?
What about referencing the control's .ControlSource? Are the names any better?

Personally, you might consider adding color backgrounds for bad controls and then not even have to name anything by name to the user msg
"the highlighted controls are bad" etc. i've done that before, it's a pretty sweet look. you'd just add a bit more complexity to your loop, and make sure to turn "good" ones back to white, but that's not too bad..
 
I have been using this module from @arnelgp and @oxicottin for data validation. Works very well, and easy to use. Much better than a simple message.
 
I may go there eventually. I do like that look and idea.
So, when I turn on my error handling I get errors...when I turn off my error handling...no errors LOL. Plus my code check isn't working. Fun! Let's focus on the error handling part first, then I can track the validation check issue (think it has to do with how I'm initiating the save).
 
What's not working? Step through the code line by line F8, asking the immediate window plenty of questions throughout
 
I'll let you know in a moment...I turned it all off in the hopes of getting an Access error message I could decipher...nope. So let me uncomment everything and start stepping...
 
This may be quite unrelated, but one thing I'm always suspicious of is scenarios where only Null is checked for. I think that if a particular column on a record starts out as Null, and then someone opens a form to edit it, and wipes out the text in a textbox, then clicks your Save button, I'm not so sure it will always reflect as Null, but possibly a ZLS. I guess I'm not sure enough (that that's a possibility) to defend that statement, but I'm always leery of just checking for Null. Thus I always check a concatenation of "" and the value, or else the len() of the concatenation of "" and the value.

(I guess one scenario I can probably defend as definitely being a possibility is where somehow a record's column was previously literally updated to a zero length string...in that case the form's control's recordsource would definitely not reflect a Null, but you probably still want to catch it).
 

Users who are viewing this thread

Back
Top Bottom