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