Error handler problem...

[Steve Richfield]

My error handler works GREAT. However, VBA seems to have some
bugs/features that are causing it fits. The little snippet that I put
at the end of each routine looks like this:

Error_Handler:
If Error_Handler(" <routine name>", Err) = acDataErrDispla y Then
On Error GoTo 0

Stop: Resume ' Press [F8] twice to view the problem.

End If

When an error occurs and I decide to debug it, I just indicate this on
the form that pops up, and the Error_Handler routine returns
acDataErrDispla y, which then shuts off error trapping, stops so I can
gain control, I press F8 a couple of times, and I am right on the
statement that causes the problem - or am I!

Pressing F8 again then jumps into the error handling routine for the
routine that called this one. Over and over again I respond to the
same form, once for each routine in the calling list, until eventually
I get to the top. Of course, if the routine does something different
on subsequent calls, then I am in REAL trouble trying to debug complex
problems.

The fundamental problem seems to be that Resume has TWO different
functions that really need individual control:

1. It gets you back to where the problem is.
2. It re-enables higher-level error trapping.

What would seem to be needed is some way to turn higher level error
trapping off, but that doesn't seem to be possible. Failing that, some
sort of magic is needed to work around this.

So far, the only semi-workable idea seems to be to bracket all calls,
function references, etc., with lines to disable and enable the error
handler, like:

On Error GoTo 0
Call something
On Error Goto Error_Handler

Of course, many function references are in complex statements that may
fail for reasons quite aside from problems in the included function,
so doing this would leave some errors un-handled and really make a
mess of programs.

Of course, I could just trap only in event handling routines that are
always at the top of the call stack, but then I must re-execute a LOT
of code to get back to the error, that may work quite differently the
second time around.

Any ideas, thoughts, suggestions, etc?

Steve Richfield

[Allen Browne]

Hi Steve. It will be interesting to see what everyone else does.

Personally, I use MZTools (from www.mztoools.com) to drop the error handler
into each new routine with the click of a toolbar button. You can configure
your own error handler, so mine is configured to add:
'On Error Goto Err_Hander
i.e. it is commented out. During development the lines all fail at the point
where they happen. Before release, we do a global search for:
'On Error
and replace with:
On Error
so they are all activated.

Other useful techniques:
- breaking out anything that is likely to error into its own little wrapper
function;
- calling a global error handler that can just ignore things like error
2501.
- logging the errors, because users can never tell you what happened.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Steve Richfield" <go****@smart-life.net> wrote in message
news:78******** *************** ***@posting.goo gle.com...

My error handler works GREAT. However, VBA seems to have some
bugs/features that are causing it fits. The little snippet that I put
at the end of each routine looks like this:

Error_Handler:
If Error_Handler(" <routine name>", Err) = acDataErrDispla y Then
On Error GoTo 0

Stop: Resume ' Press [F8] twice to view the problem.

End If

When an error occurs and I decide to debug it, I just indicate this on
the form that pops up, and the Error_Handler routine returns
acDataErrDispla y, which then shuts off error trapping, stops so I can
gain control, I press F8 a couple of times, and I am right on the
statement that causes the problem - or am I!

Pressing F8 again then jumps into the error handling routine for the
routine that called this one. Over and over again I respond to the
same form, once for each routine in the calling list, until eventually
I get to the top. Of course, if the routine does something different
on subsequent calls, then I am in REAL trouble trying to debug complex
problems.

The fundamental problem seems to be that Resume has TWO different
functions that really need individual control:

1. It gets you back to where the problem is.
2. It re-enables higher-level error trapping.

What would seem to be needed is some way to turn higher level error
trapping off, but that doesn't seem to be possible. Failing that, some
sort of magic is needed to work around this.

So far, the only semi-workable idea seems to be to bracket all calls,
function references, etc., with lines to disable and enable the error
handler, like:

On Error GoTo 0
Call something
On Error Goto Error_Handler

Of course, many function references are in complex statements that may
fail for reasons quite aside from problems in the included function,
so doing this would leave some errors un-handled and really make a
mess of programs.

Of course, I could just trap only in event handling routines that are
always at the top of the call stack, but then I must re-execute a LOT
of code to get back to the error, that may work quite differently the
second time around.

Any ideas, thoughts, suggestions, etc?

Steve Richfield

[Steve]

Regarding the following posting on DevelopersDex, I am replying from
USENET so the whole world can read this, rather than just DevelopersDex
subscribers.

Re: Error handler problem...
From: Allen Browne
Date Posted: 11/10/2004 7:53:00 PM

Hi Steve. It will be interesting to see what everyone else does.

Personally, I use MZTools (from www.mztoools.com) to drop the error handler
into each new routine with the click of a toolbar button. You can configure
your own error handler, so mine is configured to add:
'On Error Goto Err_Hander
i.e. it is commented out. During development the lines all fail at the point
where they happen. Before release, we do a global search for:
'On Error
and replace with:
On Error
so they are all activated.

Sure, but then your customers have exactly the same problem,
as your error handler goes round and round processing the
same error over and over again.
Other useful techniques:
- breaking out anything that is likely to error into its own little wrapper
function;
- calling a global error handler that can just ignore things like error
2501.
- logging the errors, because users can never tell you what happened.
My present error handling routine does these things and MUCH
more, like composing clever search strings to search Google
Groups with a single button press, substituting better error
Messages for the cryptic ones that come with Access, etc.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.