Error Handlers

  • Thread starter Thread starter Joy M
  • Start date Start date
J

Joy M

Hi -

I would like to know when to use error handlers in my procedures.
How can you tell which procedures need them and which don't ??

Thank you!

Joy
 
Have you ever seen a code error highlighted in yellow when your code runs?
If so, and you don't want your users put in that situation, then you need to
include an error handler in almost every procedure you create.

Even a simple procedure that consists of:
DoCmd.OpenReport "Report1"
needs an error handler. For example, if the user gets impatient and presses
Ctrl+C to cancel the report (or if it is cancelled by its NoData event), you
will have to handle error 2501.

There are a (very) few things that don't need an error handler, such as a
procedure that consists of nothing but:
Beep
You could also make an exception if your routine calls a function that has
its own error hander. In general, though, you waste more time trying to
figure out if it could be be an exception than you would in just adding the
error handler. It never hurts to add it; you will get caught if you try to
skimp.

Theoretically, you can also leave out the error handler in a routine that is
only called by another routine that has error handling, since the calling
routine's error handler will trap errors generated by the child process. In
practice, this makes debugging harder IMHO, because the error may not have
been generated by the routine that reports it. Anything that helps debugging
is worthwhile, so again, use error handling in any process. (It also means
your code is more re-usable if it has its own error handler.)

If it seems like a pain to add the error handler lines to every procedure,
go to www.mztools.com and download the routine that inserts it with just a
mouse click.

You might also consider logging the errors, so you have a history of what
happened. Again this can be useful for debugging, even remote debugging if
someone else is using your database. For suggestions on how to do that, see:
Error Handling in VBA
at:
http://allenbrowne.com/ser-23a.html

That logging is what I personally do, using mztools to insert the routine in
every procedure. The mztools mouse click makes that so easy.
 
Hi Allen -

Thanks for writing, I have read many of your posts in the ngs and am quite
familiar with your name, website and advice.

I have a question about the add-in tool you recommended.

I just downloaded MZ-Tools 3.0 for VBA, and opened Access and found the Add
In Manager,
but I don't know or can't find the file to add in. I am not sure what I am
looking for,
but these don't seem to fit.

There is a MZTools3VBA folder in Programs with 7 files. They are:
a shortcut to the MZTools website,
an uninstall .exe and .dat,
a help file, that is MZTools3.chm,
MZTools3VBA.dll,
MZTools3VBA.ini,
sample.xsl

Maybe you can tell me what to do next to make my Access 2003 talk to MZTools
3.0
for VBA. And we can take it from there. I have a few more questions.

Once I get them communicating, do I type my error routine into a box and
then press a button and it gets copied into the procedure?
What about just using the error handler code already in the program, and
just copying and pasting it?

Thanks for the help! I appreciate it.

Joy
 
Hi Joy

It's been ages since I installed this thing, but I think it came with a help
file that explained how to register it. Yes, if you double-click
MZTools3.chm, that should give you the instructions to follow.

There's more troubleshooting help at their website:
http://www.mztools.com/v3/faq.htm#Installing

When you get it installed, it includes a fairly standard VBA error handler,
and the example shows how to insert the procedure name or anything else you
want. You can copy your skeleten one and paste it in the dialog (accessed
through Tools | MZTools | Options)
 
Hi Allen -

Thank you for your help. I found the MZTools 3.0 toolbar myself when I
opened the VBE.

So far I have customized and used the Module header, the Procedure header
and the Error Handler.
It looks like a good tool, I think it will save a lot of typing once I get
rolling.

I changed the template of the Error Handler. Can you check if this is okay?
I think it is.
(If someone else wants to use it, they can just copy it.)

On Error GoTo Error_{PROCEDURE_NAME}

{PROCEDURE_BODY}

Exit_{PROCEDURE_NAME}:
Exit {PROCEDURE_TYPE}

Error_{PROCEDURE_NAME}:
MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure
{PROCEDURE_NAME} of {MODULE_TYPE} {MODULE_NAME}"
Resume Exit_{PROCEDURE_NAME}

Well, I have a lot of cleaning up to do now, but using MZGTools 3.0 will
make me a more efficient programmer.

I assume the procedure body can be as long as I want, just a chuck of logic
to be executed as the result of an event or a procedure call, and I just
need
one error handler for this chunk.

Thanks again for looking out for us!

Joy
 
That looks fine, Joy.

Sounds like you are interested in what I actually do.

In Access Basic (Access 1 and 2), the label names had to be globally unique
(across the entire application), so that's why we all developed the habit of
using the procedure name as part of the label, e.g.:
Error_{PROCEDURE_NAME}

In VBA, that's no longer the case, so my personal preference is to use the
same name in all procedures:
On Error GoTo Err_Handler
That makes it easier if you copy the code to another context, or if you
rename the control.

For the same reason, I don't hard-code the module name into the proc,
because I want to be able to copy code from one module to another. So the
General Declarations of every module I write contains a private constant
named conMod, and it contains the name of the procedure, e.g.:
Private Const conMod = "Form_frmClient"

Lastly, I want to log all errors, using (essentially) the code in this link:
http://allenbrowne.com/ser-23a.html

So, the event proc template I use in MZTools is just this:
---------------
'On Error GoTo Err_Handler
'Purpose:
{PROCEDURE_BODY}

Exit_Handler:
Exit {PROCEDURE_TYPE}

Err_Handler:
Call LogError(Err.Number, Err.Description, conMod & ".{PROCEDURE_NAME}")
Resume Exit_Handler
----------------

Once the debugging is done, I then to a global search for:
'On Error GoTo Err_Handler
and replace with:
On Error GoTo Err_Handler

Hopefully it helps to see what others are doing.
 
Hi Allen,

I am following all your suggestions; the shorter labels are clearer and more
practical.

I would like to try out tLogError; it seems like a good thing to have.
I assume I put the LogError function in the module section.

I would really like to know why you comment out the line
'On Error GoTo Err_Handler
while you are debugging the application, and then uncomment this line for
production.
It seems - to me - like you are taking out the error handler that we are
going to great pains(!!) to include.

Thanks so much,

Joy
 
Fair enough, Joy. The reason is that I don't write perfect code. When it
fails, I want to be thrown into debug mode, see exactly the line that caused
the error, and be able to pause the mouse above variables to see their
content. I just find that handy until its all debugged.

It's probably just a matter of taste: that's most efficient for me.
 
Hi Allen -

Thanks for taking the time to write. You have helped me immensely.

I am getting along nicely with MZTools and I recommend others to use it.
I took out all the error handlers I had in the code, because they were all
over the place.
Now I will focus on the code itself, getting it to work,
then I will put the error handlers back in using MZTools.

I am also slowly adopting the hints on your website.

Thanks for being there for us.

Joy
 
Back
Top