Types of VFP Untrappable Errors

0. "Invalid Seek Offset" 1103 and "Error Reading File" 1104

Has anyone figured out how to trap these nasty network/server related errors: "Invalid Seek Offset" 1103 and "Error Reading File" 1104? They are sporadic under heavy network or server disk I/O conditions and always invoke the internal VFP error handler, not your ERROR method or "ON ERROR" directive. I've seen articles on corrupt CDX files, etc., but this is not what we are observing. Rather it seems to be a "glitch" reading the application EXE on a network share, and/or the file handles to open VFP tables. I've also seens posts on 'slow' network conditions causing the problem, but no suggestions on how to trap and/or recover without restarting the executable.

I had some success of trapping this error in VFP9. In other words, it may behave unpredictably - can be trapped by error handler few times and then suddenly stop.

1. Errors that don't call the error handler, you just get the default vfp error handler.

Any error that occurs in the VFP Report Writer.
I believe that errors in Report Writer are now trappable in VFP9.

Yes, but Barbara Peisch just published an excellent tip in the May 2000 issue of the FPDN (FoxPro Developers Network Of San Diego) newsletter in which she thanked Christof Wollenhaupt and FrankCazabon for pointing out that if you temporarily replace your REPORT FORM call with a MODIfy REPOrt and do a Print Preview (from within the Report Designer), VFP -- after displaying the error -- will then take you to the object that has the error. In the June 2000 issue of the same newsletter, John Overland added that by doing 'Set Sys Menu to Default' before the MODIfy REPOrt, the entire VFP system menu (and, therefore, a more complete development mode) will be available to you. -- Art BergquistThis is good, but it needs to be moved somehwere else - it dosn't change the fact that errors that occur during runtime are not trapped. -- ?CFK

Results:
Error #13 Alias 'XTEST' is not found. Line 2: select Xtest
and then line 5 causes an error dialog: "Alias 'ZTEST' is not found."

As you can see, the first error "Alias 'XTEST' is not found" is handled by the ON ERROR, contrary to Q191315 (should we start a BugsThatAren't page?)

This is part of the Non-recursive error handler. In this case it just burried the other error, never to be seen. (this is just a hypothesis ?CFK)

This isn't an example of an error within an error. The simple error handler handled the first error, then execution resumed and you're out of an error condition. The second error occurred because the alias specified in the index tag isn't open (the table was opened with a different alias). This is an untrappable error, but it's an example of the previous point ("alias not found"). -- Doug Hennig
-- What do you mean "this is an untrappable error"? It got trapped at line 2. why didn't it get trapped at line 5? Did you notice the different aliases: zTest and zTest1? -- Carl KarstenIt depends on what triggered the error. I'm guessing explicit things like SELECT XTEST get trapped but implicit things (like an alias on an index when the table is opened with a different alias) don't -- Doug HennigThis is correct: I encountered it when, in the middle of a program, a file (NEXTID.DBF) had it's CDX index file overwritten with the index for a file from a different program (NEXTID.DBW) which index file referenced a field from NEXTID.DBW ("TYPE") that didn't exist in NEXTID.DBF. The result was an untrappable "Variable "TYPE" not Found" whenever the NEXTID.DBF file was opened. Very hard to track down. -- ?wgcs

If an error occurs when you're in an "error" condition (that is, an error occurred and you haven't exited from the error routine yet using RETURN, RETRY, CANCEL, etc.), the VFP "Cancel, Ignore" error dialog appears -- Doug Hennig

Error 'Cannot access selected table', occurs mostly when closing forms that have a complicated (many views) data environment and some view based combos.
I did not know this! Where is the KB article? Does Microsoft acknowledge this? This could explain some things I've run into in the past....

In VFP 3, when the validation rule for a field is violated, VFP displays the RuleText property for the field (or an ugly generic message if the RuleText isn't filled in) in a Message Box dialog that you have no control over. In VFP 5 and later, a trappable error occurs.

2. Errors with indeterminate error handling

* If an error occurs in programmatic code called from an object method, the object's Error method is fired rather than on error. This means two different mechanisms may be used to handle an error in programmatic code, depending on how the program was called.

The previous point has an interesting side effect: if your read events statement is in a method of a global object (such as an application object), the Error method of that object in effect becomes a global error handler since the object is always in the call stack. You could do away with on error completely in this case, since it's only needed to handle errors in programmatic code not called from objects.

Here's an interesting one. This program shows that error 1707 (structural CDX not found) only occurs if an ON ERROR routine is in effect. It does not fire when an Error method exists and there's no ON ERROR.
code: _ Un Trappable Errors -3

3. Errors we can do nothing about

Error 103, "DO nesting level exceeded." (128 is the max in VFP 6). The problem here is once here, you're hosed since there are no DO levels left wherein an Error Handler can execute.

Similar, if you run out of file handles (not sure you can in the new os's), and your error handler is a separate file (not likely with built apps), you get "not enough file handles".

You can't normally trap the case where the user enters an invalid date into a Text Box; VFP displays "Invalid Date" itself and doesn't fire the Valid method of the control. You can turn off the "Invalid Date" message with set notify off, but if you want the Valid method of the control to fire (for example, to give a different message or bring up a calendar), you'll have to set the StrictDateEntry property of the control to 0-Loose. One caveat: if the user enters an invalid date, it'll get blanked, so if you want to redisplay the former value, you'll have to save it in the GotFocus method of the control and restore it in the Valid.

4. Errors that behave wierdly

If a trigger fails, the Error method of the object causing the trigger to be called is fired, not the on error routine set up by the trigger (the RIError procedure). This is a big problem: RIError sets the public variable pnError to a non-zero value, which is then used by other routines to know that the trigger has failed. Imagine the following situation: the user takes some action in a form, such as deleting a record, that causes a trigger to fail. Trigger failure causes the error handler to be called, but since the trigger was fired from an object with code in its Error method, that method gets called rather than the RIError routine in the stored procedures of the database. When the Error method is done, execution returns to the trigger code. However, since pnError hasn't changed from its original zero value, the trigger code doesn't know an error occurred, so it carries on. As a result, the trigger might just partially fail.

I have never encountered this problem, but might I suggest (and ask for viewpoints on) referring to the ON("ERROR") in any ERROR method of an object? (That is, in the Error Method of an object, check if ON("ERROR") is not blank, and if not, then call it.) -- ?wgcs

The list status command isn't quite as helpful: it only sees things affected by the current data session (such as open tables and set settings), so if the error handler is in the default session, it won't see things in the private data session of a form that caused the error. If this is important to you, you could switch to the data session of the form before using this command or you could instantiate an instance of SFErrorMgr into the oError property of the form so it's in the same data session as the form.

5. Untrappable system errors

GPF, processor exception, or a bug in VFP that the OS handles by terminating the app.

For GPFs there are two exceptions. First the official one, a GPF that occurs inside an API function or a FLL function can be trapped by VFP 6 in some cases and is reported as "API function caused an exception". Second and unofficially, if you use a wrapper FLL you can make use of C exception handling and execute one line of VFP code when a GPF occurs. But you have to know the line that possible causes the exception, and not all commands will work.

Windows System errors, like a disk not being in the disk drive, can be disabled with the Set Error Mode() API function, otherwise they cause a "Critical Windows Error message".

6. Untrappable developer errors

Algorithm errors: an endless loop, user will call it "locked up."

7. Miscellaneous pondering upon untrappable errors

My VFP8 request: Reentrant error handler. Current behavior: errors in an error handler are handled by the default VFP error handler. It is as though the first line of the error handler is ON ERROR, and trying to reset it is ignored. I would like to be able to trap errors that occur within my error handler. If I don't want to, I will issue the ON ERROR myself.
This applies to error procedures, functions, methods, events, anything that might be considered an error handler, even a nested error.

I have a prediction for what would happen if this were how VFP error handlers worked: Your program causes an error, which calls your error handler, which causes an error that calls your error handler, and on and on until the DO level limit is reached, and you get an unhandlable VFP error that freezes your system. A better suggestion: debug your error handler before you deploy.

I would like to be able to trap things like "out of disk space" when my error handler tries to log the error. With a little thought, I can avoid the loop you describe by not trying to log an error if the error is "out of disk space". (rant) Also, if we need that kind of protection, then we had better not allow a function to call itself, otherwise it would never stop, right? Maybe we need a SET ALLOWRECURSION for us advanced developers. (/rant) -- CFK

8. Untrappable user errors

Users have been known to do incredibly uninformed things like turning off the PC in the middle of a large table commit.