A place to discuss the sorts of errors we can't currently trap.
Types of VFP Untrappable Errors
0. "Invalid Seek Offset" 1103 and "Error Reading File" 1104
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.
- 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.
1. Errors that don't call the error handler, you just get the default vfp error handler.
2. Errors with indeterminate error handling
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.
- According to Doug Hennigs Error HandlingPaper:
* 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.
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".
- Not enough memory.
- According to Doug Hennigs Error HandlingPaper:
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.
- According to Doug Hennigs Error HandlingPaper (again :-):
on error doesn't trap errors in reports and in the skip for clauses of a menu; these errors are untrappable, so make sure you've tested your reports and your menus under all skip for conditions.
4. Errors that behave wierdly
- From Doug Hennigs Error HandlingPaper:
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
- Again, From Doug Hennigs Error HandlingPaper:
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
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.
- 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 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.
Category Error Handling, Category Exam 70-155 Hot Topic, Category 3 Star Topics
( Topic last updated: 2007.04.24 12:23:22 PM )