>Hi Mike.
>
>>Perhaps a "normal" use of RETURN TO would pop to the READ EVENTS events level if the objective were to terminate the main application
>
>That's not what happens -- when you RETURN TO the READ EVENTS level, you stay in the application since CLEAR EVENTS hasn't been executed. It works great. Say a form is displayed and an error occurs when the user clicks a button. RETURN TO the READ EVENTS level leaves the form open but doesn't return to the method that caused the error.
>
>That said, one issue is that if anything was done prior to the error, that isn't cleaned up. For example, if the Click method of the button creates a cursor, runs a report, then closes the cursor, and the error occurs after the cursor is created, it'll still be open.
>
>>my impression is that there is general agreement that without it, VFP's RETURN TO is a flawed command
>
>I agree with that. It'd be nice to have a TRY ... CATCH ... FINALLY construct like is being added in VB.NET, but I kind of doubt we'll ever see that.
>
>Doug

Doug - you seem to be suggesting that RETURN TO the READ EVENTS level will always get me to the right place, but I think RETURN TO an intermediate level may sometimes be more desirable. For example, consider the following scenario:

1. the main program launches the Job Control app and contains the READ EVENTS
2. Job Control launches a sub-application, XFormDBF
3. XFormDBF hits an unexpected error, raising the diagnostic message dialog
4. the user chooses to Abort from XFormDBF
5. the error handler instructs XFormDBF to initiate self-destruction
6. RETURN TO program_name pops back to the CALLER of the method that failed
Execution thus resumes at the closest possible point following the error, but not within the offending method (or UDF) itself.
7. the caller of the method that failed propagates the failure and RETURNs
I'm allowing for the possibility that there could be any number of intermediate XFormDBF stack levels between the original error location and the level of the method that invoked it (in Job Control). Each of these intermediate levels can easily detect that there was an error (ehp_success = .F.), and just do a normal RETURN, so that XFormDBF can perform its usual cleanups and its self-destruction can proceed without further delay.
8. we reach the stack depth of the Job Control method that called XFormDBF
I.e. we're back to the line that immediately follows the invocation of the aborted sub-application (which is now gonzo). Job Control can now see that XFormDBF failed and obtain the detailed error information.
9. Job Control proceeds with logging and further logic in this method
Note that the stack depth here is not generally the same as the stack depth of the READ EVENTS, but this is point where I want to resume execution in Job Control.

If at step 6 I did a RETURN TO MASTER (i.e. to the READ EVENTS level), the desired cleanups and Job Control steps would be bypassed. Wouldn't you agree that this is a reasonable situation where one might RETURN TO a level different from READ EVENTS level?

In any case, since we agree that RETURN TO is flawed (and I'll take your word for it that we won't be seeing a radically different mechanism in the foreseeable future), why not give Microsoft some encouragement to take the modest incremental step of supporting a numeric stack depth argument to this command. By the way, thanks for taking a look at my ErrHandler stuff. Judging from your observation about comments in the code, you made more than a superficial review, and I really appreciate that.

Mike