>I think, as others have pointed out, that you've hit an edge case with the VFP parser. Even going as far back as my hard-copy FPD 2.5 documentation, it's clear the clauses are meant to be exclusive. My guess is the VFP parser is not properly trimming anything after the procedure name you specify (or, alternately, spitting up a syntax error like it does when you try RETURN SomeValue TO SomeProc).
>
>FWIW, I tested your repro code in VFP6 SP5 and I see the problem you're describing. This problem does not exist in VFP9 SP1 (don't know about SP2). So, upgrading to VFP9 might be one workaround.
>
>If you're determined to stick with VFP6 SP5, then you're into the wonderful world of fuzzing. Up to now you may have been trying to return logical values .T. or .F., but there's no reason they need to be logical, as long as you can reliably return one or the other of two values of the same type.
>
>For example, you could try changing your return values to character, "Y" or "N". Or numeric, 0 or 1.
>
>But if you seriously want to get a reliable pair of values, you may need to do a lot of fuzzing. Some examples I can think of off the top of my head:
>
>- single character: make one value CHR( 0 ), the other something else
>- try increasing-length character strings, on 2^n, 2^n-1 and 2^n+1 boundaries e.g. length 3,4,5 then 7,8,9 then 15,16,17 etc. You could try long strings, up to whatever VFP's maximum literal length is ( 16M in VFP6 ) but be prepared for VFP to C5 during parsing/compilation
>
>- numeric: try combinations of -1, 0, +1. Then positive/negative powers of 2, and those values +/- 1. With testing numbers in 32-bit VFP I'd go as far as 2^32.
>
>If none of the above work, you could try other VFP variable types. For example, with dates you could try the minimum VFP date, maximum date, and an empty date. Same with DateTime etc.
>
>After that, there are near-infinite possibilities using function calls e.g.
>
>RETURN TO init NOT( NOT( m.retval ) )

Al,

I don't think the flaky return value is due to the VFP parser, because my tests show that the exact same RETURN TO ... command syntax produces different results for different error cases. My guess is that there is some sort of "stack confusion" in the VFP logic for executing the RETURN TO ... statement. I wouldn't call it "stack corruption" because the value that is returned in these flaky cases isn't a garbled result - it's consistently the value of first argument that was passed to the function that triggered the error.

There's no doubt that the RETURN TO ... clauses were meant to be mutually exclusive, as far as the person who wrote the documentation was concerned. If the RETURN TO ... command had been correctly documented, the return value might have gained greater use and been more thoroughly debugged. Anyway, I'm delighted to hear that this undocumented feature still works, and better still that the bug appears to fixed in VFP9, if I understand you correctly.

I do hope to make the switch from VFP6 to VFP9 eventually, but I haven't yet reached that threshold, so I expect to stick with VFP6SP5 a while longer. If I we're going to play the sort of game you suggest, switching to a different choice of return value conventions, I'd probably go with Agnes' simple, sure-fire approach. But none of these sorts of tricks will do. The reason for choosing .F. as the failure result is that this is the normal convention that is already widely observed. By adhering to that convention, I can provide an additional measure of error handling with no programming changes. Any other value than .F. would require extensive reprogramming, and would be highly error-prone - not a good thing, when the whole objective is improved error handling!

By the way, I did try some other ways of expressing .F., e.g. 1 = 2, and (1 = 2). Surprisingly, I got syntax errors for any parenthesized expression. The unparenthesized literal expression, 1 = 2, behaves the same as my m.retval approach: flaky result is returned for certain error cases. So I don't think the solution lies in a different way of expressing .F., but maybe some other angle will suggest itself. In the meantime, I can live with the somewhat clumsy extra tests of GlobalErr.there_was_an_error.

Thank you very much for trying out my sample program against both VFP6 and VFP9, as well as offering your ideas for practical workarounds!

Mike