Hi Fernando!

See my replies to Sergey and Larry - the VFP Help documentation for the RETURN command is in error. I can understand why you might be scratching your head about the point of all this. For a long time I dismissed the idea of using non-local returns altogether, as bad programming practice, and I would still say that is generally the case.

However, there is a legitimate application of RETURN TO ... in one very important context: error handling. Basically, it's an essential device for "popping the stack" out of a program that encounters an unanticipated error. You may want to get out of the offending program without continuing even to the next line. Otherwise, a series of unpredictable further errors could follow. You may not simply want to Ignore, Retry, or Cancel. Nor does one necessarily want to resort to a heavy-handed, context-insensitive global error handler. By definition, I'm talking about the cases where there is no explicit error trapping in the function that encounters the unexpected error.

Consider what happens if you pop out of a function call because of such an unforeseen error. What value does the function return? If you can't supply a return value in a non-local RETURN TO ... statement, the result will always be seen as .T. But if we follow the convention that a .F. indicates failure, the caller could easily notice that the function failed, without extra coding to recognize this unusual failure mechanism. Otherwise, the result of every single function call becomes untrustworthy, because of the possibility that a non-local error return has rendered the return value meaningless. That makes it necessary to code explicit checks for some additional way of indicating these unusual types of failures. Lots of extra code would be needed to rigorously protect against what are presumably very rare error cases. However, if the "unanticipated error" logic follows the convention that it pops the stack and always returns .F., it is much easier build a clean, robust model of error handling that supports localized failures and context-sensitivity.

I hope that clarified things more than confusing them! Now let me ask something of you: try to compile and run the examples I cited, and tell me what you find out using VFP6 SP5. Just create this 1-line program, calling it test.prg:

RETURN TO anything .F.

Then also try this:

RETURN TO anything 1 && that this works proves VFP Help doc is in error

For me, the first example produces a syntax error, and the second example "works". (It doesn't seem to care that there is no program called "anything", but that is not the issue.) Call the program from the VFP Command Window as a function, and display the result with this command:

? test()

Mike

>Hi Mike,
>
>According to the help file, the syntax for the Return command is:
>

>RETURN [eExpression | TO MASTER | TO ProcedureName]
>

>I never knew it was possible to append a value after ProcedureName. So it seems to me that RETURN TO ProcedureName .F. should produce a compilation error (as it's happening), while RETURN TO ProcedureName 123 compiling ok is a bug, IMO.
>
>I'm using VFP 6.0 SP5.
>
>Just curious, how it was suposed to behave such a return?
>
>Fernando