What are rules of thumb for error handlers in code?

[Max Moor]

Hi All,

I've been trying over the years to keep in the habit of putting error
handlers in my VB code. My guess is that I go overboard sometimes, putting
an error handler in a trivial sub. Othertimes, I find that I didn't go far
enough, forgetting to put one in a function that calls an SQL execute.

Having never been taught better, I'd say my rules are pretty simple...

I don't bother in trivial cases, like an event procedure that just calls
another function. I put the error code in the called function.

Otherwise, I put it in...

...any function where recordsets are being accessed or (especially)
modified.

...any function that accesses operating system or file system calls.

...any function that creates or destroys objects of any kind.

...any code I write that I look at and say, "I hope no one else ever sees
this."

...any code that futzes around in an object module I've created myself.
(I'm still new at object modules)

...any code i'm not sure of one way or the other.


All that said, deciding whether to Resume Next or bail is a whole
other set of fuzzy logic.

I'm wondering what rules of thumb others have developed for
themselves? Aside from being curious, I'd like to learn more on the
subject.

Regards,
Max

 

[Douglas J. Steele]

I put error handling in all routines, regardless of how trivial they may
seem, and I very seldom use Resume Next as an action (it would only be for a
specific error code being returned)

I usually call an error handling sub. Afraid I don't have a copy handy, but
it allows you to pass an argument that will write the error message to a
text file. (Helps for those times when the user doesn't write the message
down correctly!)

To make it easier to insert the error handling code, you might grab the free
MZ-Tools 3.0 from http://www.mztools.com/index.aspx. That's just one of the
many things it can do for you.

 

[david]

Because I used Access 2000, I put an error handler in every sub.
(Early versions of A2K had a bug that sometimes top-level
error handlers did not catch all events. )

I put top-level error handlers in form events to catch and record
all events: the error handler calls a routine that captures the line
number (ERL) and current form or recordset values. Also, no
modern version of Access displays the application name correctly
on the error message, so this allows me to correct that.

I put error handlers in intermediate functions to capture the call
stack and data in the intermediate function.

All of my error handlers have the same labels, which make them
easier to copy and paste (note I have to update the fnname):

On Error Goto Catch
....
Catch:
on error resume next
errlog(erl,me,"fnname","",true,true,false)


Some people use a push/pop strategy to capture the call stack, which
can make your Catch block simpler, but since I want a logging function
in the catch block anyway that offers no advantage. I also use the same
logging function elsewhere in the code to log non-error events.

ERL requires line numbers in the code. We don't always have line
numbers everywhere in the code, and not all lines are numbered.
For new functions, a line number every 10 lines or so puts you in
the right place. We use unique line numbers as far as possible:
repeating the same numbers in every function is like having no
primary key in a database.
(david)

 

[Tony Toews [MVP]]

I put error handling in all routines, regardless of how trivial they may
seem, and I very seldom use Resume Next as an action (it would only be for a
specific error code being returned)
Agreed.

To make it easier to insert the error handling code, you might grab the free
MZ-Tools 3.0 from http://www.mztools.com/index.aspx. That's just one of the
many things it can do for you.

I quite like it. I've customized the error routine to suit my tastes.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Max Moor]

I put error handling in all routines, regardless of how trivial they may
seem, and I very seldom use Resume Next as an action (it would only be
for a specific error code being returned)

I usually call an error handling sub. Afraid I don't have a copy handy,
but it allows you to pass an argument that will write the error message
to a text file. (Helps for those times when the user doesn't write the
message down correctly!)

To make it easier to insert the error handling code, you might grab the
free MZ-Tools 3.0 from http://www.mztools.com/index.aspx. That's just
one of the many things it can do for you.

Douglas!!!

GOOD GOD!! Where has this been all my life? I'd never heard of MZ-
Tools before, but became a hard-core believer today, the moment I saw the
"Procedure Callers" tool. I've wanted something like that for ages.

I've been playing with MZ, and have made an error handler template I
like. This makes the idea of putting error handlers in every procedure
much easier. An irrational desire to eliminate anything smelling of code
bloat still whispers to me not to put them in all procedures, but I'm
trying to fight it.

Incidentally, I use an error handling sub as well. All mine does is
make the message look pretty, but I can see where a file write would be a
good idea. I know what you mean about cutomer memory.

Thanks for pointing me to a great tool!

Regards,
Max

 

[James A. Fortune]

All that said, deciding whether to Resume Next or bail is a whole
other set of fuzzy logic.

I'm wondering what rules of thumb others have developed for
themselves? Aside from being curious, I'd like to learn more on the
subject.

Unless I'm distributing a database commercially, in which case I put
error handlers everywhere, I put as few error handlers in as possible.
I find that getting around the need to trap errors whenever possible
forces me to write cleaner, more robust code. It's similar to avoiding
RAA (Reductio ad Absurdum) proofs in mathematics. It's almost always
possible to convert an RAA proof, a.k.a. Proof by Contradiction, into a
more robust direct proof. Why is such a minuscule point so important?
Some of the greatest mathematicians in history overlooked the basic
assumptions that were made in Euclidean geometry, i.e., the Parallel
Postulate in particular (please excuse the alliteration). A more
rigorous approach to those assumptions has established the field of
Non-Euclidean geometry.

Aside from Lyle's use of error handling in making sure that open files
are closed, I find very few circumstances in which I'm forced to use
error handling. I realize that I'm in a very tiny minority of
programmers, perhaps a minority of one, but I persist in my practice.
When other programmers adapt anything I've coded, they often think I
don't know what error handling is and proceed to point out the right way
to check for things. So before opening that object, if there exists a
way to check whether the object exists and is ready beforehand, I check.
I think of this as "positive" programming" rather than the "negative
programming" of error handling. If while testing the application, it
works well without error handling, then the error handling becomes a
last resort or safety net that is likely not going to be needed.
Although it sometimes takes a little bit more code to program in that
fashion, recovering from an unexpected error can become even less
efficient. As an example of what I mean by a little bit more code, I
make sure reports are based on at least one record before opening them
(from a form) rather than rely on the NoData event after attempting to
open the report. Checking for at least one record in form code runs
surprisingly quickly and only takes a few lines of code. So my rule of
thumb is to avoid relying on error handling as much as possible.

James A. Fortune
(e-mail address removed)

I like you because you're so positive. -- Tracy White

 

[Tony Toews [MVP]]

Interesting ideas snipped.

So my rule of
thumb is to avoid relying on error handling as much as possible.

In general I agree with you. I code as much error handling as
possible although not quite to the same extent as you do.

However one difference is that I always use MZTools to insert error
handling code in all the routines. You never quite know when the
user is going to do something unexpected. I'd far sooner have the
user get an error message rather than the app terminating.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[James A. Fortune]

Interesting ideas snipped.




In general I agree with you. I code as much error handling as
possible although not quite to the same extent as you do.

However one difference is that I always use MZTools to insert error
handling code in all the routines. You never quite know when the
user is going to do something unexpected. I'd far sooner have the
user get an error message rather than the app terminating.

Tony

That is all quite reasonable. Like you I have thought through the
reasons for my choices. My users are getting quite good at making sure
that results make sense. They do cross checks and think about the
reasonableness of results. They know that after code is about a week
old that errors are pretty rare. Many do a screen capture and often
suggest the correct reason why the error occurred in their email. I
think they actually look forward to being the one to find and solve an
error. I do my best to act shocked when an error occurs, but since I
can usually debug and explain why it happened within a few minutes in
most cases, they don't go into shock. If it's a more serious error I
explain what the problem is and give an estimate of how long it will
take to fix it. Most of the code I have written has been running
happily for years without error. Almost all of the coding I do is
adding new features. Debugging takes up only about 1% of my time. If
I'm writing code that is going to be sent out to users I am not in close
contact with, like you I put error handling in every single routine.
That is, after nearly all of the testing has been done using little or
no error handling. I am quite satisfied with the results from following
my rule of thumb.

James A. Fortune
(e-mail address removed)

 

[david]

yes... and no.

Again, following A2000, I never code conditions as exception handlers.
In A2K, I went through and removed most of the few places where
I used exceptions instead of explicit checks.

This because A2K frequently crashed (GPF) when it hit
an exception, particularly an exception in a UDF in a query.

But I use error handlers in my functions. I use them to
capture, report, handle and record unexpected exceptions,
not common exceptions.

(david)

 

[James A. Fortune]

yes... and no.

Again, following A2000, I never code conditions as exception handlers.
In A2K, I went through and removed most of the few places where
I used exceptions instead of explicit checks.

This because A2K frequently crashed (GPF) when it hit
an exception, particularly an exception in a UDF in a query.

But I use error handlers in my functions. I use them to
capture, report, handle and record unexpected exceptions,
not common exceptions.

(david)

Your philosophy is not far from mine. I agree wholeheartedly that
common exceptions should not hit your error handlers. I try to account
for everything I can think of, then let error handlers handle whatever's
left. If there's a way to perform a check I don't even consider using
an exception.

James A. Fortune
(e-mail address removed)