Error Handling - multiple possible? (1 Viewer)

Number11

Member
Local time
Today, 16:29
Joined
Jan 29, 2020
Messages
607
I have this on one of my forms to show a custom error message and now need to add in a further run time error 76 when a folder is not accessable, how do i change the error handling to have more than once error message and action?

On Error GoTo ErrHandler

Code here....

Exit_ErrHandler:
Exit Sub
ErrHandler:
If Err.Number = 94 Then
Err.Clear
Else
Dialog.Box "Please ensure all mandatory fields have been completed and try again..."
DoCmd.Quit
End If
Resume Exit_ErrHandler
 

bob fitz

AWF VIP
Local time
Today, 16:29
Joined
May 23, 2011
Messages
4,717
You could use something like:
Code:
Exit_ErrHandler:
Exit Sub
ErrHandler:
 If Err.Number = 94 Then
   Err.Clear
 Else If Err.Number = 76 Then
   'Do Whatever when this happens
 Else
  Dialog.Box "Please ensure all mandatory fields have been completed and try again..."
  Resume Exit_ErrHandler:
 End If
Resume Exit_ErrHandler
 

Number11

Member
Local time
Today, 16:29
Joined
Jan 29, 2020
Messages
607
You could use something like:
Code:
Exit_ErrHandler:
Exit Sub
ErrHandler:
If Err.Number = 94 Then
   Err.Clear
Else If Err.Number = 76 Then
   'Do Whatever when this happens
Else
  Dialog.Box "Please ensure all mandatory fields have been completed and try again..."
  Resume Exit_ErrHandler:
End If
Resume Exit_ErrHandler

Thanks what i am trying to do is ,,

If err.Number = 76 then
Err.Clear
Dialog.Box "Please ensure all mandatory fields have been completed and try again..."

If err.Number = 96 then
Dialog.Box "ANOTHER MESSAGE ..."
Err.Clear

but this doesnt work at all
 

Gasman

Enthusiastic Amateur
Local time
Today, 16:29
Joined
Sep 21, 2011
Messages
14,044
Thanks what i am trying to do is ,,

If err.Number = 76 then
Err.Clear
Dialog.Box "Please ensure all mandatory fields have been completed and try again..."

If err.Number = 96 then
Dialog.Box "ANOTHER MESSAGE ..."
Err.Clear

but this doesnt work at all
If you bothered to use code tags and indented your code, you should see why it would not work.?

How can an error number be 76 and 96 ?

Your other attempt was equally flawed.
 

Number11

Member
Local time
Today, 16:29
Joined
Jan 29, 2020
Messages
607
If you bothered to use code tags and indented your code, you should see why it would not work.?

How can an error number be 76 and 96 ?

Your other attempt was equally flawed.
Rude Man

They are different runtime error codes, that they suggest you dont bother looking at this and leave someone with manors to help me
 
Last edited:

Gasman

Enthusiastic Amateur
Local time
Today, 16:29
Joined
Sep 21, 2011
Messages
14,044
Rude Man

They are different runtime error codes, that they suggest you dont bother looking at this and leave someone with manors to help me

Not trying to be rude, but merely point out the error of your ways? You are not helping yourself. :(

Yes, they are different codes and you have one nested within another. :unsure:
So if the first is true, the second is never going to work.
If the first is not true the second is also never going to work either.?

I'll leave you ro Bob.
 

bob fitz

AWF VIP
Local time
Today, 16:29
Joined
May 23, 2011
Messages
4,717
Thanks what i am trying to do is ,,

If err.Number = 76 then
Err.Clear
Dialog.Box "Please ensure all mandatory fields have been completed and try again..."

If err.Number = 96 then
Dialog.Box "ANOTHER MESSAGE ..."
Err.Clear

but this doesnt work at all
Did you try the code that I offered in my earlier post
I'll leave you ro Bob.
Thank you very much :eek:
 

Isaac

Lifelong Learner
Local time
Today, 09:29
Joined
Mar 14, 2017
Messages
8,738
Random thought on seeing the original code. I don't know how many times I see this 'habit' that people somehow got into (I think from copying/pasting internet code, and it just 'took off' like a virus), and that is, adding a label specifically intended to do nothing other than Exit Sub.
Multiple reasons why this makes no sense.

1) The end of your error handling code, core code, has no reason or need to even Exit Sub, much less obscure this further by saying GoTo, a line label, that Exits Sub.
2) If all you wanted to do was Exit Sub, you could just type "Exit Sub", rather than making it more complex to look at by saying "GoTo"..[a line label that just Exits Sub] !
3) You don't need to Exit Sub at all at the end of a simple error handler such as the one you posted. The code execution will naturally complete at that point anyway.

I don't know where this concept of "Resume [a line label that Exits Sub]" came from, and rarely comment on it, but just felt led to. Error handlers, when their complexity rises above a simple sequence of Exit Sub / Error Handler Lablel / Error Handler Code set of lines, can become VERY quickly, quite a bit more complex/difficult to troubleshoot and debug and control. The last thing that is needed is to add entirely unnecessary things to it.
Just one man's opinion.
 

Number11

Member
Local time
Today, 16:29
Joined
Jan 29, 2020
Messages
607
i gave up on this and just got the code to check if a folder existed if it does then continue with the rest of the code, if not then message box and i will keep my original 1 code working code
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 11:29
Joined
Feb 28, 2001
Messages
26,999
@Isaac - there IS an issue about "Resume" vs. "Exit Sub" and I can tell you right now, you DO need a RESUME. It is incredibly important.

Event code is, in essence, a subroutine that is triggered by an event detected by Access via whatever method it uses. A LOT of events are simply that you saved a record or you opened a form - things that Access does "behind the scenes" for you - and as a part of doing that task, Access checks for an event procedure. If you did this in a true-compiled language, you would issue a CALL to the FORM_CURRENT or FORM_BEFOREDATE routine, etc. Nothing special occurs - just a standard "programmed" call sequence to an address specified in the properties list.

Error code, however, is far more often triggered by events detected either by the operating system or by Access or JET or ACE during the processing of something that normally is NOT an event. For instance, any kind of overflow is a guaranteed error trap. There is a minuscule difference between a fault, a trap, and an interrupt in terms of their origin, but no difference in what happens next in Intel-based machines. And the fact that software can declare a fault doesn't change the fact that it is treated like a hardware problem.

Error code in VBA counts as an interrupt and definitely has an effect on the process "interrupt stack." To take an interrupt, you have to save a context that WASN'T created by a CALL verb in whatever language you are using. That means you have left stuff on the program stack that didn't get there from the event. You ALSO are in a mode that can result in locking up your process. You see, one event cannot interrupt another event, and one error usually cannot interrupt another error. But if you incorrectly dismiss the error, you leave yourself in interrupt context. You now have a "mangled" stack AND your system potentially has not correctly reset the hardware interrupt handling mechanism.

We have had numerous cases on the forum in which the problem is doing an End Sub from an Error/Trap Handler. The most common system is to crash the process. Bang, Zoom, Gone! If you go into an Error/Trap Handler, you MUST leave it by the approved method EVEN if that means a RESUME to a label on an End Sub. That is because the RESUME clears the leftover hardware implications of an error trap, allowing further traps and interrupts to be fielded. Can't find the reference right now but it was within the last two years.

Allen Browne offers this about error handling:


@Number11, the Allen Browne article gives you some sample code for the situation where you want to intercept several different but specific error numbers, so it might be interesting to you, too.
 

Isaac

Lifelong Learner
Local time
Today, 09:29
Joined
Mar 14, 2017
Messages
8,738
@Isaac - there IS an issue about "Resume" vs. "Exit Sub" and I can tell you right now, you DO need a RESUME. It is incredibly important.

Event code is, in essence, a subroutine that is triggered by an event detected by Access via whatever method it uses. A LOT of events are simply that you saved a record or you opened a form - things that Access does "behind the scenes" for you - and as a part of doing that task, Access checks for an event procedure. If you did this in a true-compiled language, you would issue a CALL to the FORM_CURRENT or FORM_BEFOREDATE routine, etc. Nothing special occurs - just a standard "programmed" call sequence to an address specified in the properties list.

Error code, however, is far more often triggered by events detected either by the operating system or by Access or JET or ACE during the processing of something that normally is NOT an event. For instance, any kind of overflow is a guaranteed error trap. There is a minuscule difference between a fault, a trap, and an interrupt in terms of their origin, but no difference in what happens next in Intel-based machines. And the fact that software can declare a fault doesn't change the fact that it is treated like a hardware problem.

Error code in VBA counts as an interrupt and definitely has an effect on the process "interrupt stack." To take an interrupt, you have to save a context that WASN'T created by a CALL verb in whatever language you are using. That means you have left stuff on the program stack that didn't get there from the event. You ALSO are in a mode that can result in locking up your process. You see, one event cannot interrupt another event, and one error usually cannot interrupt another error. But if you incorrectly dismiss the error, you leave yourself in interrupt context. You now have a "mangled" stack AND your system potentially has not correctly reset the hardware interrupt handling mechanism.

We have had numerous cases on the forum in which the problem is doing an End Sub from an Error/Trap Handler. The most common system is to crash the process. Bang, Zoom, Gone! If you go into an Error/Trap Handler, you MUST leave it by the approved method EVEN if that means a RESUME to a label on an End Sub. That is because the RESUME clears the leftover hardware implications of an error trap, allowing further traps and interrupts to be fielded. Can't find the reference right now but it was within the last two years.

Allen Browne offers this about error handling:


@Number11, the Allen Browne article gives you some sample code for the situation where you want to intercept several different but specific error numbers, so it might be interesting to you, too.
I've started to read the thread you sent, and will take it under consideration. However, I didn't quite gather anything from what you said or what I am reading that provides any meaningful difference between these two blocks of code...and I have never experienced a detrimental effect from using the second, in many years of doing so:

Code:
Sub WithResume()
On Error GoTo Errhandler
'...code

ExitSub:
Exit Sub

Errhandler:
'...some code
Resume ExitSub

End Sub

Code:
Sub WithoutResume()
On Error GoTo Errhandler
'...code


Exit Sub

Errhandler:
'...some code
End Sub

Both codes will exit the sub in, practically speaking, the same manner, albeit "on" different lines. I'll consider what you're saying, but have never seen it to be necessary in my applications, although perhaps there is some obscure benefit that I have neither realized nor cared I was missing ... But I highly doubt that most people using error handlers with this method are doing so based on any reasoning other than they saw it done somewhere..
 

Micron

AWF VIP
Local time
Today, 12:29
Joined
Oct 20, 2018
Messages
3,476
Some errors will require different handling; handle the error and e.g. resume next/just end as you're showing/close and clean up recordsets, etc.
I don't see a benefit to doing different things for the same basic effect, so I have adopted the Resume exitHere approach. I find that the number of times I'll code to simply end and do nothing else have been minimal. It usually involves recording the details, giving the user options, doing clean up - something that requires more than a simple End Function/Sub. I suppose if it was a simple procedure that required nothing else, I might just End. Hard to say.
 

Isaac

Lifelong Learner
Local time
Today, 09:29
Joined
Mar 14, 2017
Messages
8,738
Some errors will require different handling; handle the error and e.g. resume next/just end as you're showing/close and clean up recordsets, etc.
I don't see a benefit to doing different things for the same basic effect, so I have adopted the Resume exitHere approach. I find that the number of times I'll code to simply end and do nothing else have been minimal. It usually involves recording the details, giving the user options, doing clean up - something that requires more than a simple End Function/Sub. I suppose if it was a simple procedure that required nothing else, I might just End. Hard to say.
Yes, I agree with you...But it sounds like you're talking more about the general "resume" of some other clean-up, and the general purpose of error handling. I.E., doing various clean-up and code inside your error handling block. I'm not taking issue with that.

I'm specifically, and only, referring to the practice of ... At the "end" of all the error handling code, when nothing else needs to be done other than end everything, when literally all you want to do at that point is end/exit the procedure: The practice of saying "Resume LineLabel", where LineLabel is a label that does nothing other than Exit. Rather than just do nothing, which accomplishes the exact same 'ending' of the sub...It's not going to cause an issue, it's just totally redundant..
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 11:29
Joined
Feb 28, 2001
Messages
26,999
Isaac, that DOES NOT accomplish the same thing at the hardware level. You need to release the interrupt context before you release the subroutine context or else you run into program-crash situations. The "Resume" releases the interrupt context. The "End Sub" (or "Exit Sub") releases the subroutine context. Do those in the proper order or you risk crashes.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 12:29
Joined
Feb 19, 2002
Messages
42,970
I always create error traps using a Select Case. That makes them easier to read and easier to expand should you discover you need to trap additional error numbers.

Code:
Select Case Err.Number
    Case 76
        'yourcode'
    Case 81
        'your code'
    Case Else
        Msgbox Err.Number & "--" & Err.Description
        Exit Sub
End Select
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 11:29
Joined
Feb 28, 2001
Messages
26,999
Pat, you ALSO have an Exit Sub. If that is in an error trap context, it is questionable. (Unless Access has been "fixed" for that case and nobody told us, which sounds just like something M$ would do.)
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 12:29
Joined
Feb 19, 2002
Messages
42,970
Usually, I just put Resume xxx and resume at the exit procedure. That way cleanup can be done in one place if any is necessary.
 

Users who are viewing this thread

Top Bottom