[AccessD] Error Code Generator

Dan Waters dwaters at usinternet.com
Mon Sep 25 10:55:58 CDT 2006


Here is what I have developed to trap and record errors:

At the bottom of each procedure or function are these lines of code:


Private Sub SubroutineName()
On Error GoTo EH

    'Code in Sub or Function

    Exit Sub
    
EH:
    Application.Echo True
    Call GlobalErrors(txtProcessID, Err.Number, Err.Description, _
	  "Module Name", "Subroutine Name ", "ExtraInfo1", "ExtraInfo2")

End Sub


txtProcessID:  This is usually the Primary Key for the record.  Could be an
empty string.

Err.Number
Err.Description

Module Name:  This is the name of the standard module the code is in.  For a
report or form I use Me.Name.

Subroutine Name:  This is the name of the subroutine.  I have to type this
in each time because there is apparently no system function to provide the
name while the code is running.

ExtraInfo1 & ExtraInfo2:  This is an optional field that holds a variable or
expression that will capture information that is unique to this procedure or
function.  This is particularly helpful when troubleshooting.



The code above can use Select Case to handle different errors differently.

The procedure GlobalErrors will record this information, along with Date,
Time, PC Name, and UserName.

GlobalErrors can give a message to users about a certain error (i.e.,
printer-related errors), and can prevent recording a certain error if I know
it's irrelevant.

Hope this was helpful . . .


Dan Waters

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-

Think of it like this:  If you don't at least trap the error in the
procedure where it occurs, how do you expect to get that information?
Errors that are unhandled in a procedure bounce back up until they find
an error handler.  By that time, you have no idea where they originated,
you only know what the error is.  So even if you have a "global" error
handler, you still need to trap errors in the procedure so you know
where to look for the problem.

Charlotte Foust 

-----Original Message-----
Subject: Re: [AccessD] Error Code Generator

That was precisely my point. It seems the logical way to do it, but all
the generators and the built-in stuff likes the local version. I don't
get why that would be better. Given modern chip speed, it's obviously
not about jumps. Maybe all the code does compress nicely but the local
way seems so clumsy to me.

----- Original Message ----
Subject: Re: [AccessD] Error Code Generator

I do it the way you just mentioned.  I have a global errorhandler, that
receives the information I want to 'monitor' from each procedure.  It
saves time and space, and with a central point for errorhandling, I can
force things pretty easily.  (Record the errors in a db, shut the system
down,
etc.)

Drew

-----Original Message-----
Subject: Re: [AccessD] Error Code Generator

I didn't write it, but it raises a question that I have wondered about
for a while. Why is it better to embed the error routine in the
particular proc or func than to write one global error handler and pass
it the text and perhaps the proc/func name, so there's only one error
handler in the whole app? I never did understand this. Can anyone
provide some insight?

Arthur

----- Original Message ----
Subject: [AccessD] Error Code Generator

I believe someone on the list created an error generator. I believe it
might be JC? Anyway I have been using it a lot for code examples and
just to be politically correct want the owner to know. Example below
 
 
Function CopytoWss()
On Error GoTo Err_CopytoWss
    DoCmd.SelectObject acTable, "Contacts"
    DoCmd.RunCommand acCmdExportSharePointList
Exit_CopytoWss:
Exit Function
Err_CopytoWss:
        MsgBox Err.Description, , "Error in Function CopytoWss"
        Resume Exit_CopytoWss
    Resume 0    '.FOR TROUBLESHOOTING
End Function

 
Martin




More information about the AccessD mailing list