Beware of issuing NODEFAULT after an error handler has fired. Here's my sad story. I hope others will learn from it.
My standard error handler looks something like this:
LPARAMETERS nErr, cMess, cProg
< log the error>
< report error to user>
This has worked fine until the other day. I found that I couldn't get the QUIT to work, and when the error handler exited, I was still in the function or method that generated the error. This routine would then continue to execute. After that, the behaviour was unpredictable.
I tried various combinations of ON SHUTDOWN, CLEAR EVENTS, QUIT and CANCEL (e.g. ON SHUTDOWN QUIT), and even a double QUIT. Nothing solved the problem.
I eventually tracked it down. One of the forms that was active when the error occurred had NODEFAULT in its QueryUnload. As a result of the QUIT, VFP tried to close the form, hit the NODEFAULT, which interrupted the close-down sequence, and caused the QUIT to stop quitting. This caused general havoc and confusion.
My subsequent testing showed that if VFP encounters NODEFAULT anywhere after the QUIT, a similar result will occur. -- Mike Lewis
Category Error Handling
( Topic last updated: 2002.08.02 03:44:04 PM )