Walter,

>I did not mean to say this was a huge problem, but rather that people should be aware that there are some things to take care of. I think the example doug gave is a valid one and I sincerely think this should be used whenever coding in error events.

I agree with you. If the error event doesn't call an active ON ERROR, then some nasty things can happen.

>
>However,Personally I think this still is a pita to code this for every error event, therefore I stay away from coding in error events as much as possible.
>

You don't have to code this each time. I use two approaches to handle this issue in my classes:

- My CUSTOM base class contains all the error handling methods/properties. Every subclass inherits this behaviour and there's nothing I need to do.

- If I want to have access to the error handler from a class that doesn't descend from the error handler class, I ADDOBJECT() it in the init() and simply pass the call to the error handler in the error event:

PROCEDURE Init
*-- instantiate error handler
This.oErr = NEWOBJECT("Errhand", "Errhand.prg")
ENDPROC

PROCEDURE Error
LPARAMETERS nError, cMethod, nLine
      
IF VARTYPE(This.oErr) = "O"
  *-- pass error info to error handler
  This.oErr.Error(nError, cMethod, nLine)
ENDIF

ENDPROC 

There are a lot of advantages using a good error handling strategy. If you handle errors in a class, you can take advantage of many features that are not easily available with a traditional error handler. For example you can do things like the following on object level:

.lDisplayErrorMessage = .t. && should error messages be displayed?
.lLogMessages = .t. && log error messages to table/file?
.lStackMessages = .t. && stack error messages
?.nLastErrorNo && get error no of last error
?.lError && has an error occurred
.lErrorTrap && should the next error be ignored?
.lDebugMode = .t.
etc.

Since each object is responsible for error handling, you can now track, manage and handle errors by object.