[AccessD] Error Code Generator

Good points, all. And presumably the jump to a global handler would cost cycles, as opposed to a local handler. I have no idea how to measure in advance this cost nor the cost in size of 1000 local handlers. I think this has come up before but I cannot recall the answer: is there a function or some other method to capture the procname? I.e. ProcName()?

Arthur

----- Original Message ----
From: JWColby <jwcolby at colbyconsulting.com>
To: Access Developers discussion and problem solving <accessd at databaseadvisors.com>
Sent: Monday, September 25, 2006 1:01:20 PM
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