Jim,

>>It is in fact an inadequate regression test of your code.
>
>That's damned harsh, David!

But it is the truth, sorry you feel the simple truth is harsh. The code fragments Fabio posted would have in fact been caught as errors in his code by adequate regression testing.

Your examples are quite likely to throw other "true" errors that are beyond the control of VFP and fit into TRY/CATCH or error handler. Network failure is typically so catastrophic that there is no recovery possible, because it tends to casacade very rapidly.

Since this is the "defined" behavior of VFP, why should you all be expecting this to be a runtime "error" that would trigger TRY/CATCH or Error() method or ON ERROR handler?

It's one thing for this to be requested as a change to the way the language behaves. VFP has worked like this for a long time, and since backward compatability is a big issue in VFP, and that it is likely that this behavior has been put into apps, this won't unconditionally change. But a SET could be put into place that could treat this as a runtime error, to maintain compatability it would not be on by default.

It's a completely different thing for it to be declared a "bug". Which is the only point I was making when I entered the thread. Call it "gurus ganging up" if you want, you are free to your opinion on the matter. Everyone is free to their opinions on the matter, a few people have expressed them in the thread. Fabio has quite the history of shouting "bug" when it's not and that was the reason I posted my opinion.

Have I run into this issue before? Yes I have. Did I at that instant wish it was an error, momentarily I did. But when I went back to look at my code where the problem occurred, it was more easily and better fixed by a change in my code, than to rely on an error mechanism.