| Discussion |
Remote Name: 18.104.22.168
Where you end up when you Suspend depends upon the type of error handling scenario. I make the distinction between "anticipated" and "unanticipated" errors.
Anticipated errors are those where you have deliberately surrounded a section of code with error trapping logic, using the ehp_traperrors flag, as is done in the demo form when you Run a sample command line. In these cases the error is reported after the error event has actually been quietly "handled" by capturing and retaining error info. If you suspend at this point, you don't see the line where the error occurred because it's no longer on the stack by the time the error is reported.
Unanticipated errors are those detected while ehp_traperrors = .F., i.e. where there is no explicit error-checking method code. When such errors occur in a method belonging to an ErrHandler-based object, I call them "exceptional" errors. When these errors are caught by the ON ERROR handler associated with an ErrHandler-based object (i.e. based on ErrHForm), I call them "abnormal" errors. In either case, these unanticipated errors are reported by the generic error handler, so a Suspend will indeed allow you to go directly to the program line where the error occurred, further down the stack.
Also note that if you want to be able to Suspend during the otherwise quiet handling of an "anticipated" error, you can enable a piece of diagnostic tracing logic in the generic error handler code. To do this, you should set ehp_tracelevel to a non-zero multiple of 2 (see the macro named ERRH_TRACE_ERRHERR in errhandl.h). If you've also set ehp_diagmode = .T., this will bring up the diagnostic message dialog, allowing you to Suspend while the line that triggered the error is still on the stack.
To see examples of these situations, run the errhdemo application and try out the following: