By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,365 Members | 3,095 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,365 IT Pros & Developers. It's quick & easy.

Any way to check current On Error status

P: n/a
I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.
Nov 13 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you tell us why you need this, perhaps we can respond better.

Short answer: yes, but you'll need to keep track of the call stack
yourself.

-Tom.

I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.


Nov 13 '05 #2

P: n/a
On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you tell us why you need this, perhaps we can respond better.

Short answer: yes, but you'll need to keep track of the call stack
yourself.

-Tom.

I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.


Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.

The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.

If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.

What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.
Nov 13 '05 #3

P: n/a
On Sun, 06 Jun 2004 04:56:18 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you outfit every proc with a Push and a Pop function to push and
pop its name on and off the stack, and you would pass an extra
argument indicating if this proc is using an error handler or not,
then you could in an error handling block walk that stack and check
the presence or absence of an error handler.

Unfortunately, unlike the .NET environment, in Access you don't have
access to the stack, so the above is doing a similar thing the hard
way.

Personally, I don't make a distinction between case 1 and case 2, and
I "always" implement case 1.

-Tom.

On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you tell us why you need this, perhaps we can respond better.

Short answer: yes, but you'll need to keep track of the call stack
yourself.

-Tom.

I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.


Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.

The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.

If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.

What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.


Nov 13 '05 #4

P: n/a
On Sat, 05 Jun 2004 22:21:56 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 04:56:18 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you outfit every proc with a Push and a Pop function to push and
pop its name on and off the stack, and you would pass an extra
argument indicating if this proc is using an error handler or not,
then you could in an error handling block walk that stack and check
the presence or absence of an error handler.

Unfortunately, unlike the .NET environment, in Access you don't have
access to the stack, so the above is doing a similar thing the hard
way.

Personally, I don't make a distinction between case 1 and case 2, and
I "always" implement case 1.

-Tom.

On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you tell us why you need this, perhaps we can respond better.

Short answer: yes, but you'll need to keep track of the call stack
yourself.

-Tom.
I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.


Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.

The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.

If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.

What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.


Of course, what I wrote above was slightly backward. If you use case 2 when
you should use case 1, you crash out of Access. If you use case 1 when you
use case 2, the calling code can proceed thinking the called code did its job.
About 3/4 of the time, that's OK. Other times, the calling code will error
again because something it expected didn't happen, and the user now has to
click OK 2 or more times for a single error. A few other times, the
procedures could both be handling part of a transactional process (either
formally with a database transaction, informally with some sort of deletion
roll-back), and data can be left in an invalid state according to the business
rules.

I thought of custom the stack idea, but I don't know if code can always be
guaranteed to be stacked in the order of execution. For instance, a timer
event could fire while a modal form is open (though I avoid timer events when
I can). There are probably other ways this could happen that I haven't
thought of.
Nov 13 '05 #5

P: n/a
On Sun, 06 Jun 2004 05:53:28 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

I'm not concerned about your Timer example. When the timer ticks, your
proc is added to the stack, the code runs and finishes, Pop is called,
the stack frame cleans up, and you're back where you were.
In all the years I have used the Push/Pop code, with additional bounds
checking added, I have never seen it fail, other than due to
programmer error (Exit Function without Pop).

-Tom.
On Sat, 05 Jun 2004 22:21:56 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 04:56:18 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you outfit every proc with a Push and a Pop function to push and
pop its name on and off the stack, and you would pass an extra
argument indicating if this proc is using an error handler or not,
then you could in an error handling block walk that stack and check
the presence or absence of an error handler.

Unfortunately, unlike the .NET environment, in Access you don't have
access to the stack, so the above is doing a similar thing the hard
way.

Personally, I don't make a distinction between case 1 and case 2, and
I "always" implement case 1.

-Tom.

On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:

On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you tell us why you need this, perhaps we can respond better.

Short answer: yes, but you'll need to keep track of the call stack
yourself.

-Tom.
>I'm trying to figure out if there is a way to generate standard error handlers
>that "know" if the calling code has an error handler in effect (On Error Goto
><label> or On Error Resume Next) before deciding how to respond. Does anyone
>know if this is possible.

Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.

The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.

If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.

What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.


Of course, what I wrote above was slightly backward. If you use case 2 when
you should use case 1, you crash out of Access. If you use case 1 when you
use case 2, the calling code can proceed thinking the called code did its job.
About 3/4 of the time, that's OK. Other times, the calling code will error
again because something it expected didn't happen, and the user now has to
click OK 2 or more times for a single error. A few other times, the
procedures could both be handling part of a transactional process (either
formally with a database transaction, informally with some sort of deletion
roll-back), and data can be left in an invalid state according to the business
rules.

I thought of custom the stack idea, but I don't know if code can always be
guaranteed to be stacked in the order of execution. For instance, a timer
event could fire while a modal form is open (though I avoid timer events when
I can). There are probably other ways this could happen that I haven't
thought of.


Nov 13 '05 #6

P: n/a
On Sun, 06 Jun 2004 10:17:29 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 05:53:28 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

I'm not concerned about your Timer example. When the timer ticks, your
proc is added to the stack, the code runs and finishes, Pop is called,
the stack frame cleans up, and you're back where you were.
But the whole point of the stack is that it's supposed to track whether the
calling code has an error handler. The timer event will be on the stack,
possibly after another procedure with an error handler, wit the timer event
was not called by that code. Thus, the error handler will think it should
re-raise the error, and crash out of Access when it does. I'm a little
concerned about this, but more concerned about other types of out-of-order
events I might not have considered.
In all the years I have used the Push/Pop code, with additional bounds
checking added, I have never seen it fail, other than due to
programmer error (Exit Function without Pop).
So perhaps, the timer is the only possible case?

-Tom.
On Sat, 05 Jun 2004 22:21:56 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 04:56:18 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

If you outfit every proc with a Push and a Pop function to push and
pop its name on and off the stack, and you would pass an extra
argument indicating if this proc is using an error handler or not,
then you could in an error handling block walk that stack and check
the presence or absence of an error handler.

Unfortunately, unlike the .NET environment, in Access you don't have
access to the stack, so the above is doing a similar thing the hard
way.

Personally, I don't make a distinction between case 1 and case 2, and
I "always" implement case 1.

-Tom.
On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:

>On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
><no****@nospam.nospam> wrote:
>
>If you tell us why you need this, perhaps we can respond better.
>
>Short answer: yes, but you'll need to keep track of the call stack
>yourself.
>
>-Tom.
>
>
>>I'm trying to figure out if there is a way to generate standard error handlers
>>that "know" if the calling code has an error handler in effect (On Error Goto
>><label> or On Error Resume Next) before deciding how to respond. Does anyone
>>know if this is possible.

Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.

The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.

If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.

What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.


Of course, what I wrote above was slightly backward. If you use case 2 when
you should use case 1, you crash out of Access. If you use case 1 when you
use case 2, the calling code can proceed thinking the called code did its job.
About 3/4 of the time, that's OK. Other times, the calling code will error
again because something it expected didn't happen, and the user now has to
click OK 2 or more times for a single error. A few other times, the
procedures could both be handling part of a transactional process (either
formally with a database transaction, informally with some sort of deletion
roll-back), and data can be left in an invalid state according to the business
rules.

I thought of custom the stack idea, but I don't know if code can always be
guaranteed to be stacked in the order of execution. For instance, a timer
event could fire while a modal form is open (though I avoid timer events when
I can). There are probably other ways this could happen that I haven't
thought of.


Nov 13 '05 #7

P: n/a
> >I'm not concerned about your Timer example. When the timer ticks, your
proc is added to the stack, the code runs and finishes, Pop is called,
the stack frame cleans up, and you're back where you were.
But the whole point of the stack is that it's supposed to track whether the calling code has an error handler. The timer event will be on the stack,
possibly after another procedure with an error handler, wit the timer event was not called by that code. Thus, the error handler will think it should
re-raise the error, and crash out of Access when it does. I'm a little
concerned about this, but more concerned about other types of out-of-order
events I might not have considered.


????

If on entry your Timer proc does the appropriate push/pop then you will know
where you are. Access/VBA are not multithreaded so you can just go with
that.
In all the years I have used the Push/Pop code, with additional bounds
checking added, I have never seen it fail, other than due to
programmer error (Exit Function without Pop).


So perhaps, the timer is the only possible case?


No, things will work there too as long as you recognize the limitations?
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
Nov 13 '05 #8

P: n/a
On Sun, 6 Jun 2004 16:19:55 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote:
>I'm not concerned about your Timer example. When the timer ticks, your
>proc is added to the stack, the code runs and finishes, Pop is called,
>the stack frame cleans up, and you're back where you were.
But the whole point of the stack is that it's supposed to track whetherthe
calling code has an error handler. The timer event will be on the stack,
possibly after another procedure with an error handler, wit the timer

event
was not called by that code. Thus, the error handler will think it should
re-raise the error, and crash out of Access when it does. I'm a little
concerned about this, but more concerned about other types of out-of-order
events I might not have considered.


????

If on entry your Timer proc does the appropriate push/pop then you will know
where you are. Access/VBA are not multithreaded so you can just go with
that.


The order of calling and returning will be correct, but since the timer event
is called by Access, not by the previously called code, if it raises an error,
the previously called code's hanlder will not be invoked. Access will close.
Am I missing something?
>In all the years I have used the Push/Pop code, with additional bounds
>checking added, I have never seen it fail, other than due to
>programmer error (Exit Function without Pop).


So perhaps, the timer is the only possible case?


No, things will work there too as long as you recognize the limitations?


Well, whether I'm right about the timer event issue or not, it's a special
case that hardly occurs, and I know what to do there - so I guess the custom
call stack idea is sounding solid enough. I'll just go with that.

Thanks for the help all,

- Steve J.
Nov 13 '05 #9

P: n/a
On Sun, 6 Jun 2004 16:19:55 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote:

....
????

If on entry your Timer proc does the appropriate push/pop then you will know
where you are. Access/VBA are not multithreaded so you can just go with
that.


I just realized what I was thinking of that you might not have been. Access
VBA is not technically multi-threaded, but there are times, such as when a
dialog box is open when timer events (and other events) can fire and be
processed when they were not called by the running code that's waiting for the
dialog. The calling order does not mirror the internal the call stack in such
cases.
Nov 13 '05 #10

P: n/a
"Steve Jorgensen" <no****@nospam.nospam> wrote...
The order of calling and returning will be correct, but since the timer event is called by Access, not by the previously called code, if it raises an error, the previously called code's hanlder will not be invoked. Access will close. Am I missing something?


Since you will have an error handler in your Timer event proc, it will not
bubnble any further up.

--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
Nov 13 '05 #11

P: n/a
H vae you looked at the call stack in such instances while debugging? It
handles the issue quite nicely; so can you.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:jv********************************@4ax.com...
On Sun, 6 Jun 2004 16:19:55 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote:

...
????

If on entry your Timer proc does the appropriate push/pop then you will knowwhere you are. Access/VBA are not multithreaded so you can just go with
that.
I just realized what I was thinking of that you might not have been.

Access VBA is not technically multi-threaded, but there are times, such as when a
dialog box is open when timer events (and other events) can fire and be
processed when they were not called by the running code that's waiting for the dialog. The calling order does not mirror the internal the call stack in such cases.

Nov 13 '05 #12

P: n/a
On Sun, 6 Jun 2004 20:16:43 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote:
"Steve Jorgensen" <no****@nospam.nospam> wrote...
The order of calling and returning will be correct, but since the timer

event
is called by Access, not by the previously called code, if it raises an

error,
the previously called code's hanlder will not be invoked. Access will

close.
Am I missing something?


Since you will have an error handler in your Timer event proc, it will not
bubnble any further up.


Ah, but there's the rub. The whole idea I was trying to come up with is a
generic error handler that can tell if it was called from another procedure
that has an error handler or not.

I never worried about this when it was just me maintaining my code, but I'm
working with someone else on a project who doesn't feel comfortable that he
understands my logic on which procedures need what kind of error handling.
Nov 13 '05 #13

P: n/a
"Steve Jorgensen" <no****@nospam.nospam> wrote...
Ah, but there's the rub. The whole idea I was trying to come up with is a
generic error handler that can tell if it was called from another procedure that has an error handler or not.
That is the whole idea? Darn, because thats a lousy idea even when its only
part of the idea.
I never worried about this when it was just me maintaining my code, but I'm working with someone else on a project who doesn't feel comfortable that he understands my logic on which procedures need what kind of error handling.


So always have error handlers in every event proc, and then you are covered.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
Nov 13 '05 #14

P: n/a
>> I never worried about this when it was just me maintaining my code, but I'm
working with someone else on a project who doesn't feel comfortable that he
understands my logic on which procedures need what kind of error handling.
So always have error handlers in every event proc, and then you are covered.


Now, the thread has gone full circle. Putting error handling in every
procedure is fine, but what goes into each error handler still depends what
the context of the procedure will be. If the calling procedure should stop if
the called code fails, the called code should re-raise the error - or just not
handle it if no clean-up is neeeded and if we weren't talking about putting
error handlers everywhere (though adding the proc name to Source is nice).

If a procedure is always invoked by a user action, it should report the error
to the user and do a normal procedure exit. That's how I always write my
error handlers, and that always works as advertised, but since the new code
owner doesn't get this, I was trying to see if I could get the code to be
intelligent enough to do it automatically, and just eliminate this as a
maintenance issue for the programmer.
Nov 13 '05 #15

P: n/a
Not really -- in the case of event code you can just about always assume
that it is Access that is "on the stack" triggering the event, and just trap
the errors yourself. All you need to do is use your brain about the event
itself to decide what to do..... and add comments for the maintenance
programmer.

Thinking about them is great, but all the time you are spending trying to
make the code automatic would probably be better served enhancing comments
enough so that when they are debugging they are not lost.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:07********************************@4ax.com...
I never worried about this when it was just me maintaining my code, but I'm working with someone else on a project who doesn't feel comfortable that he understands my logic on which procedures need what kind of error
handling.
So always have error handlers in every event proc, and then you are
covered.
Now, the thread has gone full circle. Putting error handling in every
procedure is fine, but what goes into each error handler still depends what the context of the procedure will be. If the calling procedure should stop if the called code fails, the called code should re-raise the error - or just not handle it if no clean-up is neeeded and if we weren't talking about putting error handlers everywhere (though adding the proc name to Source is nice).

If a procedure is always invoked by a user action, it should report the error to the user and do a normal procedure exit. That's how I always write my
error handlers, and that always works as advertised, but since the new code owner doesn't get this, I was trying to see if I could get the code to be
intelligent enough to do it automatically, and just eliminate this as a
maintenance issue for the programmer.

Nov 13 '05 #16

P: n/a
On Mon, 7 Jun 2004 03:32:13 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote:
Not really -- in the case of event code you can just about always assume
that it is Access that is "on the stack" triggering the event, and just trap
the errors yourself. All you need to do is use your brain about the event
itself to decide what to do..... and add comments for the maintenance
programmer.
Uh - yeah. That's pretty much what I said to the other programmer.
Thinking about them is great, but all the time you are spending trying to
make the code automatic would probably be better served enhancing comments
enough so that when they are debugging they are not lost.


Well, it's always worth taking some time to see if concerns can be moved
completely out of the programmer's way because it saves time and reduces bugs
later - on future projects as well. If there's no way to do it, there's no
way to do it, but I like to go ahead and try to explore the options.
Nov 13 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.