Error trapping code

[Thelma Lubkin]

I use code extensively; I probably overuse it. But I've been using
error trapping very sparingly, and now I've been trapped by that.

A form that works for me on the system I'm using, apparently runs into
problems on the system where it will actually be used, and since I
used so little error-trapping it dies very ungracefully.

I will of course try to fix whatever is causing the error and add
error-trapping to the functions where the problem surfaces, but I
realize that I need to add error-trapping code with a more liberal
hand.

My question is, therefore, should error-trapping code bookend every sub
and function? If not, what criteria do I use to decide whether to add
it or not?
--thanks, thelma

[Allen Browne]

Yes, if the application matters, use error-trapping in every sub and
function in your application.

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

"Thelma Lubkin" <th****@alpha2.csd.uwm.edu> wrote in message
news:df**********@uwm.edu...

I use code extensively; I probably overuse it. But I've been using
error trapping very sparingly, and now I've been trapped by that.

A form that works for me on the system I'm using, apparently runs into
problems on the system where it will actually be used, and since I
used so little error-trapping it dies very ungracefully.

I will of course try to fix whatever is causing the error and add
error-trapping to the functions where the problem surfaces, but I
realize that I need to add error-trapping code with a more liberal
hand.

My question is, therefore, should error-trapping code bookend every sub
and function? If not, what criteria do I use to decide whether to add
it or not?
--thanks, thelma

[rkc]

Thelma Lubkin wrote:

My question is, therefore, should error-trapping code bookend every sub
and function? If not, what criteria do I use to decide whether to add
it or not?

Functions, methods that return a value to a calling procedure, don't
necessarily need error handling, but the calling code certainly should
have it. Objects(class modules) should trap an error and pass it on to
the client code.

[John Welch]

Is there an easy way to insert basic error trapping into all subs after the
fact? Just the basic : msgbox err.number & err.description stuff
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:43*********************@per-qv1-newsreader-01.iinet.net.au...

Yes, if the application matters, use error-trapping in every sub and
function in your application.

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

"Thelma Lubkin" <th****@alpha2.csd.uwm.edu> wrote in message
news:df**********@uwm.edu...

I use code extensively; I probably overuse it. But I've been using
error trapping very sparingly, and now I've been trapped by that.

A form that works for me on the system I'm using, apparently runs into
problems on the system where it will actually be used, and since I
used so little error-trapping it dies very ungracefully.

I will of course try to fix whatever is causing the error and add
error-trapping to the functions where the problem surfaces, but I
realize that I need to add error-trapping code with a more liberal
hand.

My question is, therefore, should error-trapping code bookend every sub
and function? If not, what criteria do I use to decide whether to add
it or not?
--thanks, thelma

[Allen Browne]

See:
www.mztools.com

They have a set of tools you can download for VBA without charge. It
installs a toolbar that (amongst other things) lets you insert your
procedure stub and/or error handling with a single mouse click in any
procedure, including references to the name of the procedure if you wish.
That's what I use.

It handles the MsgBox stuff if you wish. What I do is to get it to call a
generic error-handing procedure, passing in the value of Err.Number,
Err.Description, and other information such as the name of the procedure
that caused this error, the name of the module, any parameters that I am
aware of at design time that I might want, and a flag to indicate whether to
show this message to the end user or not.

There are some major advantages to calling a single procedure like that:
a) If I decide to change the way the error handler works, there's just one
piece of code to update.

b) I can handle some errors in a generic way, such as the many errors that
can indicate inability to save a record at the moment, or the 2501 you
receive when a user or NoData event cancels opening a report etc.

c) I can log the errors. In my first Access database (version 1), I asked
users to write the error message down. They never did. It occured to me to
record the errors in a table. Just a couple of times a year, this proves
really useful, especially to debug something that is happening on one
machine and not another. If you want more info on how to do that, copy it
from:
Error Handling in VBA
at:
http://allenbrowne.com/ser-23a.html

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

"John Welch" <j+ohnw+elch@cal+central.com (remove +'s)> wrote in message
news:df*********@enews2.newsguy.com...

Is there an easy way to insert basic error trapping into all subs after
the fact? Just the basic : msgbox err.number & err.description stuff
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:43*********************@per-qv1-newsreader-01.iinet.net.au...

Yes, if the application matters, use error-trapping in every sub and
function in your application.

--
"Thelma Lubkin" <th****@alpha2.csd.uwm.edu> wrote in message
news:df**********@uwm.edu...

I use code extensively; I probably overuse it. But I've been using
error trapping very sparingly, and now I've been trapped by that.

A form that works for me on the system I'm using, apparently runs into
problems on the system where it will actually be used, and since I
used so little error-trapping it dies very ungracefully.

I will of course try to fix whatever is causing the error and add
error-trapping to the functions where the problem surfaces, but I
realize that I need to add error-trapping code with a more liberal
hand.

My question is, therefore, should error-trapping code bookend every sub
and function? If not, what criteria do I use to decide whether to add
it or not?
--thanks, thelma

[Allen Browne]

Thelma, an example might help to explain rkc's suggestion.

Say you have a procedure that calls another proc like this:
Sub MySub
Debug.Print MyFunction()
End Sub
Function MyFunction()
MyFunction = 6
End Function

Now if you add error handling to just MySub, and an error occurs when it
calls MyFunction, the error handler in MySub will catch the problem when it
calls MyFunction and the problem occurs.

While that's true, I prefer to add error handling to MyFunction anyway. The
main reason is that I find it much easier to track down an error if I know
what procedure caused it. Particularly when you get one proc that calls
another that calls another ..., I'm too lazy to try to track down which one
actually caused the error, when I can get Access to gell me just by using
error handling in each one. The other reason is that later on I may need to
call MyFunction() from somewhere else, so I really prefer just to have the
error handlers in place anyway.

As a general rule, it is easier to write software than to maintain it, so
anything you can do to write maintainable code is worth the effort.

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

"rkc" <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in message
news:N_*****************@twister.nyroc.rr.com...

Thelma Lubkin wrote:

My question is, therefore, should error-trapping code bookend every sub
and function? If not, what criteria do I use to decide whether to add
it or not?

Functions, methods that return a value to a calling procedure, don't
necessarily need error handling, but the calling code certainly should
have it. Objects(class modules) should trap an error and pass it on to the
client code.

[Thelma Lubkin]

Allen Browne <Al*********@SeeSig.Invalid> wrote:
: Thelma, an example might help to explain rkc's suggestion.

: Say you have a procedure that calls another proc like this:
: Sub MySub
: Debug.Print MyFunction()
: End Sub
: Function MyFunction()
: MyFunction = 6
: End Function

: Now if you add error handling to just MySub, and an error occurs when it
: calls MyFunction, the error handler in MySub will catch the problem when it
: calls MyFunction and the problem occurs.

Actually, I don't really understand that. Suppose I have

Sub MySub
Debug.Print MyFunction(0)
End Sub
Function MyFunction(denom as Integer)
MyFunction = 6/denom
End Function

Why does execution return to MySub so that the error can be trapped
instead of simply dying in MyFunction?

: While that's true, I prefer to add error handling to MyFunction anyway. The
: main reason is that I find it much easier to track down an error if I know
: what procedure caused it. Particularly when you get one proc that calls
: another that calls another ..., I'm too lazy to try to track down which one
: actually caused the error, when I can get Access to gell me just by using
: error handling in each one. The other reason is that later on I may need to
: call MyFunction() from somewhere else, so I really prefer just to have the
: error handlers in place anyway.

I intend to write a single function that gets offending
sub/function name, etc, as parameters, to report error messages
to the end-user, and after reading your earlier post, I think
that I'll use it to save those messages for the
developer/maintainer as well. Do you just add a table to the
database for these?

Thank you for the help. --thelma

: --
: 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.

: "rkc" <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in message
: news:N_*****************@twister.nyroc.rr.com...
:> Thelma Lubkin wrote:
:>
:>> My question is, therefore, should error-trapping code bookend every sub
:>> and function? If not, what criteria do I use to decide whether to add
:>> it or not?
:>
:> Functions, methods that return a value to a calling procedure, don't
:> necessarily need error handling, but the calling code certainly should
:> have it. Objects(class modules) should trap an error and pass it on to the
:> client code.

[Allen Browne]

Answers embedded.

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

"Thelma Lubkin" <th****@alpha2.csd.uwm.edu> wrote in message
news:df**********@uwm.edu...

Allen Browne <Al*********@SeeSig.Invalid> wrote:
: Thelma, an example might help to explain rkc's suggestion.

: Say you have a procedure that calls another proc like this:
: Sub MySub
: Debug.Print MyFunction()
: End Sub
: Function MyFunction()
: MyFunction = 6
: End Function

: Now if you add error handling to just MySub, and an error occurs when it
: calls MyFunction, the error handler in MySub will catch the problem when
it
: calls MyFunction and the problem occurs.

Actually, I don't really understand that. Suppose I have

Sub MySub
Debug.Print MyFunction(0)
End Sub
Function MyFunction(denom as Integer)
MyFunction = 6/denom
End Function

Why does execution return to MySub so that the error can be trapped
instead of simply dying in MyFunction?
If you have added error handling to MySub, then when it calls a function
that generates an error, control is returned from the failed function to the
calling procedure's error handler.

The example above does not have error handling, so that won't happen until
you add the error handler to MySub.
: While that's true, I prefer to add error handling to MyFunction anyway.
The
: main reason is that I find it much easier to track down an error if I
know
: what procedure caused it. Particularly when you get one proc that calls
: another that calls another ..., I'm too lazy to try to track down which
one
: actually caused the error, when I can get Access to gell me just by
using
: error handling in each one. The other reason is that later on I may need
to
: call MyFunction() from somewhere else, so I really prefer just to have
the
: error handlers in place anyway.

I intend to write a single function that gets offending
sub/function name, etc, as parameters, to report error messages
to the end-user, and after reading your earlier post, I think
that I'll use it to save those messages for the
developer/maintainer as well. Do you just add a table to the
database for these?

Yes, that's what I do. The setup of the table is explained in the article:
http://allenbrowne.com/ser-23a.html

Some developers prefer to write the errors out to a text file, so that even
if the database corrupts you still have the log. IME, that's not a big
enough issue to be worth the effort. The bigger question is whether you use
a single network log for all workstations, or log separately on each
workstation. I prefer logging to a local workstation, because that still
works reliably even if the problems are caused by the network itself.

HTH

[Rick Brandt]

Allen Browne wrote:

Some developers prefer to write the errors out to a text file, so
that even if the database corrupts you still have the log. IME,
that's not a big enough issue to be worth the effort. The bigger
question is whether you use a single network log for all
workstations, or log separately on each workstation. I prefer logging
to a local workstation, because that still works reliably even if the
problems are caused by the network itself.

Agreed. My main corporate app logs errors locally, sends me an Email of every
trapped error (there is a table entry that enables/disables that), and also
provides a menu item that allows them to Email me the entire error log file.

It was amazing how many "incidental" errors were happening and not being
reported that I was able to clear up when I added the automatic Email feature.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Allen Browne]

Thanks, Rick.

I do provide an option for the user to export/email/fax a report based on
the error table, but have not given them the automatic email option.

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

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:MU****************@newssvr11.news.prodigy.com ...

Allen Browne wrote:

Some developers prefer to write the errors out to a text file, so
that even if the database corrupts you still have the log. IME,
that's not a big enough issue to be worth the effort. The bigger
question is whether you use a single network log for all
workstations, or log separately on each workstation. I prefer logging
to a local workstation, because that still works reliably even if the
problems are caused by the network itself.

Agreed. My main corporate app logs errors locally, sends me an Email of
every trapped error (there is a table entry that enables/disables that),
and also provides a menu item that allows them to Email me the entire
error log file.

It was amazing how many "incidental" errors were happening and not being
reported that I was able to clear up when I added the automatic Email
feature.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

Thelma Lubkin <th****@alpha2.csd.uwm.edu> wrote in
news:df**********@uwm.edu:

Actually, I don't really understand that. Suppose I have

Sub MySub
Debug.Print MyFunction(0)
End Sub
Function MyFunction(denom as Integer)
MyFunction = 6/denom
End Function

Why does execution return to MySub so that the error can be
trapped instead of simply dying in MyFunction?

You have to understand the difference between custom error handling
and VBA's default error handling. The code above has no error
handlers, so if you pass 0 as the denominator, VBA's error handler
will kick in as soon as you attempt division by zero.

Now, with an error handler, VBA looks for an error handler to pass
the error to, and it works its way up the call stack until it finds
one. Say you have 3 subroutines:

Sub1() <- has error handler
Sub2() <- no error handler
Sub3() <- no error handler

If Sub1() calls Sub2() which calls Sub3(), and an error occurs in
Sub3(), it will bubble up the call stack until it finds an error
handler, in this case, the one in Sub1(). If it finds no error
handler, it's passed off to the default VBA error handler, which
will give you the Debug/Cancel dialog, and report the error in the
subroutine in which it occured.

It works exactly the way event handlers for controls, etc., work --
each control has a default AfterUpdate event, and when you add code
to the AfterUpdate event, you are adding onto that default behavior
(or even overriding it, as in the case of BeforeUpdate events that
cancel the update). An error handler works the same way -- it
supplements or overrides the default handling of errors.

For some reason it's customary to call letting an error be handled
by VBA an "unhandled error," even though VBA does, in fact, handle
the error. The difference, though, is that in a runtime app, an
unhandled error (i.e., one that bubbles up to the VBA error handler)
will cause your app to quit, whereas all handled errors will recover
gracefully.

During coding, I often turn off my error handlers so I can see
exactly where the error occurred, but I have to remember to turn
them back on. This would not be necessary if VBA exposed the line
number that generated the error, but it doesn't. It would be an
extremely useful feature if it did, and can only be replicated with
a great deal of effort.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Fri, 2 Sep 2005 23:13:48 +0800, "Allen Browne" <Al*********@SeeSig.Invalid>
wrote:

Yes, if the application matters, use error-trapping in every sub and
function in your application.

I used to think that, and now I don't. I'd say that now, about 1/3 to 1/2 of
the procedures I write have error handling. If you do put error handling in
every function, certainly don't just trap the error and return as if nothing
happened (like much wizard-generated code does) if the calling procedure will
depend on the called procedure having worked without an error in order to
proceed correctly.

It's far better to have no error handler at all than to do the wrong kind of
error handling, and many procedures don't -necessarily- need any.

I put error handling into the following 3 categories.

1. Event procedure error handling:
If you implement no other kind of error handling, implement this kind. Any
error that is not trapped before the end of an event handling procedure will
cause the application to exit completely if it is run-time, and will ask the
user if they want to debug the code if not. This is really ugly, so for
safety, any event handling procedure that could have a failure should have
error handling. The only time one of these procedures might not need error
handling is when it only calls other procedures that do have error handling,
and only passes constant value arguments or perhaps a reference to "Me" (a
control name string is a constant - a control is not).

2. Expected failure traps:
These traps are important and should almost always be implemented, but some
are less important than others and can be left out so long as type 1 handing
is in place (above).
- If you try to open a form or a report, there's a good chance the object will
have reason to cancel the open event, so you need to catch the error, check
for the error number, do nothing in that case, and proceed with default error
handling otherwise, possibly by just re-raising the error so the calling
procedure can handle it.
- If you do anything with files or database objects, there could be a missing
file, a lock conflict, etc. In general, these errors should be trapped, and a
friendly message given to the user. A procedure called by another might just
close the objects it has open, then re-raise the error to the calling
procedure which in turn handles the error by presenting the friendly message.

3. Unexpected failure traps:
All code has bugs, and sometimes bugs cause errors to be raised.
Unfortunately, there's not usually much we can do about them except present
the error description and fail the current operation. Traps, in these cases,
are useful only to add info that tells the programmer what procedure had the
error.
I tend not to add these handlers anymore, since well-orgainized code keeps
call trees shallow and concerns well enough separated, that there are usually
only one or 2 places a particular error could have come from. I find the
benefit of shorter code that's easier to read (without error handlers) to be
higher than te benefit of more complete error message data. This is, of
course, a matter of personal style, and I won't say anyone is wrong if they
disagree with me.
By the way, if you use these error handlers and do something with the name of
the module/procedure, remember that you must get those string values right (or
close) in the first place, and keep them that way as things get renamed. I
frequently see code with many of these strings having the same value in
multiple procedures because the programmer copied the error handler block, and
forgot to change the text.

[Darryl Kerkeslager]

"Steve Jorgensen" <no****@nospam.nospam> wrote

I frequently see code with many of these strings having the same value in
multiple procedures because the programmer copied the error handler block,
and
forgot to change the text.

Yeah, and talk about tough errors to track down!

IME, the most difficult errors to find are the ones caused by [my] sloppy
cut-and-paste.
--
Darryl Kerkeslager

Power corrupts.
Absolute power corrupts absolutely.
Knowledge is power.
See www.adcritic.com/interactive/view.php?id=5927

[John Welch]

Thanks so much Allen, I got MZ tools and it's very helpful. It will ease my
programming a bunch.

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:43*********************@per-qv1-newsreader-01.iinet.net.au...

See:
www.mztools.com

They have a set of tools you can download for VBA without charge. It
installs a toolbar that (amongst other things) lets you insert your
procedure stub and/or error handling with a single mouse click in any
procedure, including references to the name of the procedure if you wish.
That's what I use.

It handles the MsgBox stuff if you wish. What I do is to get it to call a
generic error-handing procedure, passing in the value of Err.Number,
Err.Description, and other information such as the name of the procedure
that caused this error, the name of the module, any parameters that I am
aware of at design time that I might want, and a flag to indicate whether
to show this message to the end user or not.

There are some major advantages to calling a single procedure like that:
a) If I decide to change the way the error handler works, there's just one
piece of code to update.

b) I can handle some errors in a generic way, such as the many errors that
can indicate inability to save a record at the moment, or the 2501 you
receive when a user or NoData event cancels opening a report etc.

c) I can log the errors. In my first Access database (version 1), I asked
users to write the error message down. They never did. It occured to me to
record the errors in a table. Just a couple of times a year, this proves
really useful, especially to debug something that is happening on one
machine and not another. If you want more info on how to do that, copy it
from:
Error Handling in VBA
at:
http://allenbrowne.com/ser-23a.html

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

"John Welch" <j+ohnw+elch@cal+central.com (remove +'s)> wrote in message
news:df*********@enews2.newsguy.com...

Is there an easy way to insert basic error trapping into all subs after
the fact? Just the basic : msgbox err.number & err.description stuff
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:43*********************@per-qv1-newsreader-01.iinet.net.au...

Yes, if the application matters, use error-trapping in every sub and
function in your application.

--
"Thelma Lubkin" <th****@alpha2.csd.uwm.edu> wrote in message
news:df**********@uwm.edu...
I use code extensively; I probably overuse it. But I've been using
error trapping very sparingly, and now I've been trapped by that.

A form that works for me on the system I'm using, apparently runs into
problems on the system where it will actually be used, and since I
used so little error-trapping it dies very ungracefully.

I will of course try to fix whatever is causing the error and add
error-trapping to the functions where the problem surfaces, but I
realize that I need to add error-trapping code with a more liberal
hand.

My question is, therefore, should error-trapping code bookend every sub
and function? If not, what criteria do I use to decide whether to add
it or not?
--thanks, thelma