[AccessD] Error Code Generator

Hi John!

Well - I did say that I can set up a Select Case within the procedure to
handle the errors that are unique to that procedure or function.  What you
showed below is exactly what I do.

As for the number of cycles, I probably average about 1 error per week for a
mature system.  So - it's not a big deal.

The primary purpose of the global error handler is to handle unexpected
errors in a way that provides me the information to begin to know what to do
next.  I don't think it's unwieldy, just practical.

By the way, I looked at my example again, and it looks like I have a
procedure to do nothing but trap errors, with one of these for every other
procedure or function!  No!  The error handling within each procedure or
function starts at the Continue statement EH:

Dan Waters

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
Sent: Monday, September 25, 2006 12:01 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Error Code Generator

Well, that certainly works for logging all errors.  What happens when you
simply want to ignore a certain type of error:

	On err = 15 resume next

Or 
	On Err = 15 resume ExitLabel

Or you want to do other processing:

	On err = 15 CallMyFunction

When a global error handler exists, then all of the LOGIC associated with
handling that error is now out in the error handler function, away from the
code where the error is happening.  For documentation it helps to have the
error cases commented

	Select case err
	case 15,16,18	'These cases occure when...
		Do something for these errors
		Resume ExitLabel
	case 97		'This case occurs when...
		Do something else here
		Resume next
	Case else
		Error Logger
				'Call the global error logger to log any
cases not specifically trapped above
	end select 

There are errors that occur that are simply expected and ignored.  Why call
the error handler for these cases.  A simple resume next is all that is
needed.  Others require local action (open a recordset, change a null to a 0
etc.) then a resume next.  This kind of stuff belongs in the function where
the error occurred.

What happens when you delete an entire function?  All of the error handling
is out in your error handler and is accumulating trash.  If the error case
is in the function then the error handler is deleted along with the
function.

I have no quibble with having an error LOGGER to call to log any errors that
are unexpected and not handled in the local function (until they can be
handled there) or even to log expected errors, but to handle every error in
your program in one humongus error handler is unwieldy IMHO.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Monday, September 25, 2006 11:56 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Error Code Generator

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

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com