Here's my take:
NEVER expect to have figured for all errors. In note of that, you should
have error handling in every sub/function. Or at least, you should
understand that when there is no error handling in a procedure, the error is
carried back through the calling procedures until an error handler is found,
or, until the last calling procedure is found. If none of these have error
handling, you will see the halt code error dialog box. Realize that if you
get this box, your code is now in what they call a "broken" state, and
depending on the complexity of your project, this could have a devastating
effect to your data. Hardly worth the risk IMHO.
That said, the ONLY time I leave error handling out of a procedure is when I
have a specific reason to do so (when I want the error handled by the calling
procedure instead of the current procedure). And this is not very often
(unless you're in the habit of writing class modules).
When you start expanding on your project and getting into using global
variables or properties that store core data for the session, you don't want
there to be any chance whatsoever that this data might get messed up (which
it will on an unhandled error), because that could seriously mess some things
up. So yes, my advice is to include it on every procedure. You'd be amazed
at what crazy errors access can spit out, sometimes even months after
testing/using the app.
1) Does every function, procedure or sub need error trapping? I, for instance have the following
in the On Open of a form:
Me!fieldname.SetFocus.
I can understand that if I remove the field from the form it might trigger an error, but come on.
What if, 6 months down the road, you do some editing to the app and
reconstruct the underlying query of the form, and that field is no longer
available? Are you sure you will remember that when the time comes? Are you
willing to go through and check all of your lines of code manually to make
sure you've got everything covered before you accidentally screw something
up? (and btw, you can't set the focus to a field, rather you set it to the
control that the field is bound to).
2) Is there any generic error handling routines that can be called from, say the on open of a form
instead of creating error handling for every one of a forms subs?
No, but there's a free tool that makes it extremely easy (after setting up
you can have error handling in every procedure in your app in about
10minutes). Go to
www.mztools.com and download the addin. It's priceless.
3) Do I need to trap for errors I suspect might occur? But then if I was able to that I probably wouldn't need
error handling.
Again, the major point here is that you will never think of every error that
will happen, no matter how good you are. It's just the way it is... As far
as trapping errors you suspect might occur, there's two schools of thought on
that, the first is to handle the case outside of the error handler (as an
if/then condition in the procedure), the second is to handle it within the
error handler itself. Either way, you should be account for "expected"
errors. "Unexpected" errors are the ones that cause the real problems and
raise the requirement for good error handling.
There's umpteen different ways that people tend to go about handling
errors... I've been through a lot of them, from global functions to handle
logging and notifying of errors, down to a few lines in each procedure. IME,
large global functions to handle all sorts of errors are generally a pain.
What happens if you get an error inside you error handler? At one point I
had a global handler set up that would log the error, and, depending on the
source of the error, would roll back the app to a particular state (such as
user logged out, or restart, or close the active form, etc). It theory its a
great idea, but the extra pains you have to go through to make sure it will
never fail is a complete nightmare.
FWIW, the handler that I've settled on after a few years trying different
things is this one:
Public Function SomeFunc() As Datatype
On Error Goto Err_Proc:
'-----
your sub here
'-----
Exit_Proc:
Exit Function
Err_Proc:
Select Case Err.Number
Case Else
MsgBox Err.Number & ": " & Err.Description
End Select
Resume Next
Resume
End Function
the above gives you a base that can be inserted into any procedure, and the
Select Case statement allows you to handle expected errors easily without
having to change anything other than adding a Case # line.
All in all, I think error handling is extremely important for any even
halfway serious work. It's the backbone of your application. Even if you
just tool around with Access to keep your CD collection at the house, you
will never regret having taken the time to set up SOME sort of handling.
mztools lets you insert a handler at the click of a button.
For further reading, do a google search on "Chip Pearson Error Handling"...
he goes through everything from top to bottom (written for excel but
applicable to any office vba host app).
hth
--
Jack Leach
www.tristatemachine.com
"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
