Re: Suspend button

From: mda
Keywords: ErrHandler
Remote Name: 24.218.251.34
Remote User:
Date: 04/16/02
Time: 18:49

Comments

Hi Doron,

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:

1. check the Diag Mode checkbox, to enable use of the diagnostic message dialog
2. enter an invalid command line and click Run
   This illustrates the "anticipated" error case.  Click on Suspend, and then Debug.  You'll see that method errhdemo.errhcm_run is already beyond the &cmd line where the error actually occurred.  Resume and click OK to return back to the demo form.
3. now set Trace Level to 2 and Run the invalid command line again
   This time, you'll get a tracing message that says "The Error event trapped an anticipated error."  If you Suspend and Debug at this point, you'll see that you are halted beneath the execution of the &cmd line, i.e. with the line where the error occurred still on the stack.  If you then Resume and click OK, you'll continue to the point where the error is normally reported, bringing up the dialog a second time.
4. reset the Trace Level to 0 and click on the demo form's Error Test1 button
   This triggers an "exceptional" error, on an invalid assignment statement deliberately placed in method ErrHDemo.ERRHCM_TestError.  Use Suspend and Debug to see where you are.  (The additional logic in this method is for the purpose of testing optional tracing and various ways of continuing, i.e. OK, Retry, or Abort).
5. now try the demo form's Error Test2 button
   This triggers an "abnormal" error.  If you Suspend and Debug at this point, you'll see that an ON ERROR handler was used to catch an error (bogus assignment statement) in errhdemo.cmderrtest2.click.  The reason this triggered an ON ERROR instead of an Error event is that only methods of the ErrHandler-based object trigger its Error event.

Brought to you by SpaceTime Systems.  All rights reserved.