How would you ... (error handling)

[Daniel]

Hello,

I have seen the basic coding used for error handling:

******
on error goto ....

Exit_sub:
Exit sub

error:
do something
resume
******

I was wondering if there was another way to handle this issue that wouldn't
require always adding such code to each form or report event? Perhaps,
unknown to me, their is an approach using a custom function that could do
the same job but reducing the redundant coding?!

Thanks for the help,

Daniel

 

[Rick Brandt]

Hello,

I have seen the basic coding used for error handling:

******
on error goto ....

Exit_sub:
Exit sub

error:
do something
resume
******

I was wondering if there was another way to handle this issue that wouldn't
require always adding such code to each form or report event? Perhaps,
unknown to me, their is an approach using a custom function that could do
the same job but reducing the redundant coding?!

Thanks for the help,

Nope. You can have a common function that you use to handle all errors, but you
still need the basic skeleton code in your post to call that function or
routine.

 

[Brian]

Hello,

I have seen the basic coding used for error handling:

******
on error goto ....

Exit_sub:
Exit sub

error:
do something
resume
******

I was wondering if there was another way to handle this issue that wouldn't
require always adding such code to each form or report event? Perhaps,
unknown to me, their is an approach using a custom function that could do
the same job but reducing the redundant coding?!

Thanks for the help,

Daniel

The error handler add-in which is included in the Office Developer Tools (or
whatever Microsoft is calling it these days) very effectively takes the
tedium out of adding standard error handling to every procedure. The
default template that it uses didn't suit me, but it's very easy to
customise.

 

[Daniel]

Rick,

Could you possibly post an example of a sub and th error function so
that I could understand a bit better how to go about this.

Thank you for the help,

Daniel

 

[Rick Brandt]

Rick,

Could you possibly post an example of a sub and th error function so
that I could understand a bit better how to go about this.

Sorry I don't currently have access to my error handling function code, but the
basic usage is...

Sub SubName

On Error GoTo ErrHandler

Egress:
Exit Sub

ErrHandler:
ErrorMessages "SubName"
Resume Egress
End Sub

So as you can see whenever SubName has an error the function ErrorMessages() is
run to handle the error in a consistent manner.

I created my global error handler function "ErrorMessages" because I wanted
better documentation and notification of errors so I could correct for them. In
the user interface it really does nothing more than provide a slightly more
organized message box. I display error number <new line> error description, and
loop through the errors collection so I can display all of them in one message
box which doesn't happen with many types of errors otherwise. It also
identifies the current object automatically and I can add text to the function
call to tell me the exact sub/function that was running when the error occurred.

The "meat" of my handler is that all errors are logged to a text file on the
users drive and also Emailed to me. The last is a recent option I added (I do
have a table entry where I can turn it off and on) and I can tell you that it
was quite a revelation. I can now state with high confidence that users ALMOST
NEVER report errors that do not obviously restrict them from continuing in their
work. They just acknowledge the error message and move on. The fact that some
important process that is supposed to happen in the background might not be
happening doesn't even occur to most of them.

The first few weeks of having that Email feature was a bit torturous, but I
eventually got a lot of stuff fixed and the numbers are now down to an "almost
satisfactory" level. I'm shooting for zero tolerance, but I suppose that is
impossible.