>>You can simply Copy the ON ERROR example on VFP help!
>>Then, add further control on Error number.
>>
>
>The trouble is, for SQL statements and REPLACE and DELETE (and I'm sure others), no error is generated, a dialog box is opened, demanding that the user find some file that the user has no idea about. What's more the open dialog doesn't even say what file it wants you to find! A very ungraceful way to handle an unexpected situation.

Well, it can't have any idea of which file to ask for - this happens when you're in a workarea where nothing is USEd, and you issue a record- or table-oriented command, it has no table to do it on, and can't have an idea where to guess from.

For a moment, I thought it would be nice if it could raise an error, but then what would you do in the error handler, after receiving a "no table in use in the selected area" error code? The same error could be returned from many different situations, so you'd be in the middle of a long choice of possible causes.

OTOH, having a possibility that a table/record oriented command executes with no table is something which should be thoroughly eradicated while testing. Imagine having something record-related command in some kind of a loop; how many times would an error handler be invoked? Or, worse, is there any way to get out of such a loop via error handler? It can set an error variable, which we can test for in the loop header? Why don't we test for having a table in a first place?

Whew, it took me too long to say "I like it as it is".

>The bad part is, if this ever happens in code running on a web server in response to a hit, this 'find' dialog is equivalent to a hang. THere's no way around it, no matter how good you error handler is.

No way around it, indeed, even if we could use an error handler. There's a way away from it, checking for alias() in time.