Though this will throw and exception out of the error method it really does't escalate the original error (In my opinion it should). Your code will throw a "user thrown error" to a higher handler. So in a sense it's not really escalating the exception.


You want a automatic escalation of the Errot trapped
or of a error fired within the Error ?

First is a bad behaviour, second is a need behaviour.

Error() trapping is like to this sequence:

- call a object procedure

- check procedure parameters
 TRY
   executeMethodCode
 CATCH WHEN ProcedureIsFill('Error')
     Error(...)
 ENDTRY

But VFP it implement this logic, with a approssimative coding.

The strange facts are:

- next must call higher trap, but it call master VFP trap and this is a implementation problem
Procedure Error(nError, cMethod, nLine)
       THROW	&& this fire a not trappable error
ENDPROC

- next must call higher trap, but it call the first higher TRY/ENDTRY, 
  it skip the Error() of the parent object, and this is a implementation problem

Procedure Error(nError, cMethod, nLine)
    TRY
       THROW
    CATCH WHEN .F.
    ENDTRY
ENDPROC

- next is correct
Procedure Error(nError, cMethod, nLine)
    TRY
       THROW
    CATCH WHEN .T.
    ENDTRY
ENDPROC

- next is a implementation problem because VFP ignore the second THROW
Procedure Error(nError, cMethod, nLine)
    TRY
       THROW
    CATCH WHEN .T.
	THROW
    ENDTRY
ENDPROC

Then, if you want a escalation to a external TRY/ENDTRY, it is simple:

Procedure Error(nError, cMethod, nLine)
    TRY
      * write the error code within a TRY/ENDTRY trap
      =nError+cMetho
    FINALLY
      * before exit trap code
    ENDTRY
ENDPROC

For a true OOP escalation, VFP cannot do it.