Search Down atm - Error Handling Code

[isladogs]

This is my standard error handling code:

Private Sub cboError_AfterUpdate()

On Error GoTo Err_Handler

    'Procedure code here
    
Exit_Handler:
    Exit Sub

Err_Handler:
    strProc = "cboError_AfterUpdate"
    MsgBox "Error " & Err.Number & " in " & strProc & " procedure: " & _
        Err.Description, vbExclamation, "Application Error"
    Resume Exit_Handler
    
End Sub

If you have something like MZ Tools, you can add line numbering & pin the error to a particular line

To test your error handling, you can raise an error using a line like

Err.Raise 94

which will return 'Invalid use of Null' as the error description

 

[MajP]

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.

For demo purposes I tried to force a ZLS and found it is really not that easy to create. I think you see it more when you do an import from something else like Excel where it can be very common. With that said I usually check all three Null, ZLS, and empty spaces. The latter is even harder to recreate, but again not too uncommon with an import from Excel.

if Trim([fieldName] & "") = "" then

 

[MajP]

Here is a demo of that validation code in use since the thread does not have one. It is so easy to use and works so well. You get a message and the colored controls. Half the time when you write your own, you can get into circular event logic.

 

[JMongi]

Ok, I am thoroughly confused. So, just background. This portion of code has been working correctly for days...
Question 1 - Can I code my VB error handler to give me Access errors and descriptions? I thought that was what this did:

MsgBox "Error " & Err.Number & ": " & Err.Description, vbExclamation, "Program Error"

But Err.Number comes up 0 and Err.Description is blank.

 

[MajP]

As far as I can tell you never exit your function even if no error is encountered. So you call the error handler every time and thus err.number = 0 and description = null since no error was really encountered.

 

[MajP]

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
Exit Function
ErrHandler:
Call ErrProcessor
FormNullChk = False 'I don't want to save a record if there is an error.
Exit Function

End Function

 

[JMongi]

So error #1 is thrown when opening my second form. It's been working fine (i.e. no access errors).
So, here is the code to launch the form:

Private Sub EditButton_Click()
'Hide Project Form
    Me.Form.Visible = False
'Launch Project Task Form
    DoCmd.OpenForm "FrmProjHours", acNormal
End Sub

No issues with the above code.
Here is the Load Code

Private Sub Form_Load()
On Error GoTo ErrHandler

'Set the form size, 1440 is the TWIPS per inch
    Me.InsideWidth = 8 * 1440
    Me.InsideHeight = 8.25 * 1440

'Set the top left form location
    DoCmd.MoveSize 0.5 * 1440, 0.5 * 1440

ErrHandler:
Call ErrProcessor
Exit Sub

End Sub

It errors on the DoCmd.MoveSize.

 

[MajP]

Same problem as already discussed.. No exit and go direct to error handler.

 

[JMongi]

Oh! I had an error handler in another part that I rewrote....one moment....

 

[JMongi]

I read somewhere that I need to use resume because getting out of the error handler any other way causes wonkiness....fixing...

 

[MajP]

As @Isaac pointed out that is BS. You do not need a resume unless you are going to do something with it. It does nothing that exiting the code does not do.

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

It is as silly as you have to set object variables to nothing. No one can tell you why, and few can show an example where it is needed, but they will emphatically tell you so.

 

[Isaac]

Ok, I am thoroughly confused. So, just background. This portion of code has been working correctly for days...
Question 1 - Can I code my VB error handler to give me Access errors and descriptions? I thought that was what this did:

MsgBox "Error " & Err.Number & ": " & Err.Description, vbExclamation, "Program Error"

But Err.Number comes up 0 and Err.Description is blank.

Then either one of the following had to of been true: 1) there was never an error, or 2) there was an error, but it got cleared.

 

[JMongi]

Well, quitting time has arrived. I tweaked my code. But, I will have to test it tomorrow. Thanks all!

 

[Isaac]

As @Isaac pointed out that is BS. You do not need a resume unless you are going to do something with it. It does nothing that exiting the code does not do.


It is as silly as you have to set object variables to nothing. No one can tell you why, and few can show an example where it is needed, but they will emphatically tell you so.

The only time I've found it handy to set to nothing is when opening a *lot* of DAO recordsets. (maybe a function that runs for every record in a query that opens a recordset). I've gotten some weird error, maybe it was out of memory, I can't remember...

HOWEVER...even that, might have been just remember to close them. Ha. I can't remember

 

[JMongi]

I duly acknowledge your superior experience in Access and VBA. However, my troubleshooting bears out what I stated. Adding the various Exit statements did not solve the problem. Reconfiguring my error handler to be as below fixed the problem.

ExitHandler:
Exit Sub

ErrHandler:
Call ErrProcessor
Resume ExitHandler

It was not a random Joe on the internet that warned of not using Resume. It was actually a page I've seen referenced a few times on AWF here.

The relevant line is:

All forms of the Resume clear or reset the Err object.

This seems to match what Isaac posted in #32

Then either one of the following had to of been true: 1) there was never an error, or 2) there was an error, but it got cleared.

It appears that without the "Resume" I was getting phantom errors.

 

[JMongi]

After some more coffee and taking a bigger picture view I think I understand what @MajP and @Isaac were saying.

Forgetting for a moment what the code itself does, a label within my code does not stop execution of the code so adding....

'Some Code Here

Exit Handler:
Exit Sub 'Sub is Exited

is the same as:

'Some Code Here

Exit Sub 'Sub is Exited

In both cases I end up with the graceful exit from my sub. Meaning that adding the tag and Exit Sub was the same as adding the Exit Sub that @MajP was pointing out in the first place. I must have had a missing "Exit Sub" somewhere that was fixed by adding in the handler tag and Exit Sub.

I do find the comment about the "Resume" command interesting but it doesn't appear to be germane to my particular issues.

 

[JMongi]

Long Thread Summary:

Error handling issues fixed by adding the appropriate "Exit Sub" commands so that my error handler subroutine was not automatically called whether there was an error or not. Thanks to @MajP and @Isaac for their expert assistance.

 

[JMongi]

Issue #2 - My form validation function may or may not be working. If it's anything like my previous coding issues its probably doing exactly what I'm telling it do. It just actually happens to be NOT what I want to have happen! LOL

Now that the error issue is sorted. Let me step through the function and see what's shaking.

 

[MajP]

You misinterpreted what Chip said and what Isaac and I said.

Moreover, Resume is the only way, aside from exiting the procedure, to get out of an error handling block. Do not use the Goto statement to direct code execution out of an error handling block. Doing so will cause strange problems with the error handlers.

Once you enter the error block either your code needs to end or you need a resume if the code is not going to exit.. DO NOT USE a GOTO to get out of the error block..
What @Isaac and I stated is the same as above. If you are going to exit the procedure anyways (which is about 99% of the time) you do not need a resume that sends you back to a location that will tell you to exit.

IMO that is like you are about to exit the building and a sign at the door says before exiting to read another sign at the head of the room. That signs says exit the building.
You see it done all the time, but I believe this is a hold over from some wizards that would create this block. The intent IMO was to allow you to edit the block, not prescriptive of an approach.

But yes you were "falling" through your code every time. So you called the error handler when no error is encountered. This mistake is common unless like many of us you use an ADD-IN to make your error handlers. Many use MZTOOLS which creates default blocks.

 

[JMongi]

I understand what you are stating and what Chip is stating in the portion you quoted. It would be useful if you could explain what he meant by the portion that I quoted in post #35

All forms of the Resume clear or reset the Err object.

Are you saying that it is not necessary to do this clear or reset if you just end your error handler?