>Daniel,
>
>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 could 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. If have an error handler class, then you can instantiate it in the init() 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.

- 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
This.oErr = NEWOBJECT("Errhand", "Errhand.prg")
ENDPROC

PROCEDURE Error
LPARAMETERS nError, cMethod, nLine
      
IF TYPE("This.ioErr") = "O" AND NOT ISNULL(This.ioErr)
This.ioErr.Error(nError, cMethod, nLine)
   ENDIF
   
   RETURN
   *-- EOF Procedure Error -----------------------------------------------------

I don't think it's such a pita once you know how to address the issue. There are many advantages of a good error handling strategy.