>You can do things like that reliably with objects that provide a single point of entry/exit, for example an .Execute method or when you use the object as an 'exception frame' around a function.
>
>Combining directed return with value return (i.e. RETURN foo TO bar) does not work reliably - at least not in the case of error handlers - but you could use an object property for the intended return value. Private variables would work too (and they would be impervious to the 'lost THIS' problem) but they make code brittle and messy.
>
>

define class CFoo as Relation
>
>   protected c_Result
>   c_Result = ""
>
>   protected procedure Try_
>      error "meow"
>
>   protected procedure CallBoundary_Cmtz1y29LSNvPxEsM3G6T_
>      this.Try_
>
>   function Execute
>      this.c_Result = ""
>      this.CallBoundary_Cmtz1y29LSNvPxEsM3G6T_
>      return this.c_Result
>
>   procedure Error (nError, cMethod, nLine)
>      this.c_Result = message()
>      return to CallBoundary_Cmtz1y29LSNvPxEsM3G6T_
>
>enddefine

>
>The call boundary needs to be there and it needs a unique name because the code in .Try_ could call other functions named 'Execute' directly or indirectly, and a RETURN TO Execute would pick the nearest match on the stack frame which is not necessarily the .Execute of the CFoo class. On the other hand you wouldn't want to force users of your class to call a function named 'Execute_hZhv3JSWM5ar69l9iGEBX'. *g*
>
>Your _ASSIGN hack could be made to work in this manner but I'd recommend rethinking the problem instead. Using directed return from an _ASSIGN method is really bad design that makes even GOTO-riddled code look clean by comparison.

Hi Stefan


Thanks for your input. As Cetin metioned , caller should decide how to react the returned result. You explaination lead me to think in another direction. Thanks.

Arnold