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.