We ran into some error trapping/supression issues at my company. I'm not sure if the error trapping was supposed to work out of the box or not, but from what I can see, there are some issues. After looking into the problem, here's what I found:
CASE 1: If the DEBUG.TXT file is missing, run the ON ERROR logic - The first problem is obvious: if no ON ERROR setting exists, the error is supressed! If an ON ERROR setting does exist, it quite probably references a variable that at this stage has gone out of scope. For example, the common practice of trapping an expected error like ON ERROR llErrFlg=.T. would never work because llErrFlg goes out of scope at this stage!
CASE 2: If the lErrorVFP flag is set, generate the error - In order for this to happen, the debug file must exist. Also, the lErrorVFP property must be set to true (it is false by default). In this event, any errors intended to be trapped in code such as ON ERROR llErrFlg=.T. will flag an error. The other problem is that the line of code that generated the error will not show up in the debugger as the offender. It is the line ERROR (nError) that will show. This can cause some debugging headaches.
CASE 3: All other circumstances - This appears to be the case in most of the code. Under this circumstance a DODEFAULT() is issued. The problem is, this is the superclass. There is no default code to run! So the error is supressed! In other words, if you have your DEBUG.TXT file, and lErrorVFP is .F. (which is the default) any errors generated at the form level will be supressed!
It seems to me that the only solution is to remove all error event code at the C-Level and create a generic ON ERROR routine. Am I missing something?
Donald J. Bouchier
SKAMP, a CAI Company
©2001 Donald J. Bouchier |
