>>When an error occurs on an object, the object's error method has priority over any try/catch. If the object doesn’t have an error method, but it is a member of a class that does, then that error method will be used.

In my testing of Try/EndTry this statement is kindof true. If a class is defined with code in its Error method and has another method that is wrapped in a Try block, the behavior I've seen ignores the Error event.

Repro code:

oTest = CREATEOBJECT("TryEndTryTest1")
CLEAR
TRY
   oTest.RaiseException()
   ?"Next line Exception was handled"
   CATCH TO oX
   ?"Exception Caught"
ENDTRY 

DEFINE CLASS TryEndTryTest1 as Custom
   ADD OBJECT TryMember as TryEndTryMemberTest1
   FUNCTION Error(nError as Number ,cMethod as String, nLine as Number) 
      ?"Object definition Exception handled"
   ENDFUNC 
   
   FUNCTION RaiseException()
      SELECT XYZ && Handled in Error Method
      this.TryMember.RaiseException() && Has exception Handled in outer Try block
   ENDFUNC 
ENDDEFINE 

DEFINE CLASS TryEndTryMemberTest1 as Custom
   FUNCTION Error(nError as Number ,cMethod as String, nLine as Number) 
      ?"Member Object Exception handled"
   ENDFUNC 

   FUNCTION RaiseException()
      Try
         SELECT PDQ && Handled in Outer Try block
      ENDTRY 
   ENDFUNC 
ENDDEFINE 

>>The error method of an object (or if it’s an object member, it’s containing class) takes precedence over try/catch because classes are meant to be encapsulated. If a class designer were to write code with its own error method to achieve a particular behavior, a user of that class should not be able to break the class behavior simply by using a TRY/CATCH in the client code.

I've had use cases where it would have been nice to have the option to escalate an error to a higher handler from the code in the error method. Being able to do this sure would be a nice feature.