>Hi Mike. > >>>That's very interesting, Doug. I didn't know about ASTACKINFO(). Do you know of any other upcoming VFP7 features related to error handling in general? I was hoping to see a RETURN TO , for example. Thanks for the info. > >>That last msg didn't display right - I meant RETURN TO stack_depth_argument, but it didn't like my use of angle brackets. - mda > >No, RETURN TO hasn't changed. I noted comments in your error handler code that indicated limitations with RETURN TO, particularly with respect to multiple routines with the same name on the call stack, which in general are true. However, normally you should RETURN TO the method or routine that contains the READ EVENTS command, so hopefully you'll only have one of those in your app. > >Doug
Perhaps a "normal" use of RETURN TO would pop to the READ EVENTS events level if the objective were to terminate the main application, but what I'm trying to do is something less drastic: to terminate only the sub-application that failed, and allow the calling application to make its own decision about how to proceed further. I don't want to CANCEL or QUIT, I want to do a clean, localized Abort in response to an unanticipated error. So my Abort procedure is to pop the stack as little as possible, by returning to the caller of the method or UDF that encountered the error. I don't want to make a simple RETURN to the offending code, because this will resume execution in a questionable section of code that didn't expect the error. I don't want to RETURN TO MASTER, because it prevents me from providing a more graceful mode of failure.
For example, suppose the main application is a Job Control facility, whose job is to run a bunch of modular sub-applications (e.g. my XFormDBF app) in some highly automated fashion. If XFormDBF encounters an unexpected problem, or the operator deliberately aborts it, I want XFormDBF to fail cleanly, but I don't want Job Control to be unduly disrupted. Job Control needs to log the error and proceed with other jobs according to it's own contingency plan, which requires its understanding job interdependencies (something that XFormDBF knows nothing about).
It seems to me that the concept of such a localized Abort capability is an important provision in a general error handling scheme that supports robust, modular, nested components. Getting back to the RETURN TO stack_depth argument, my impression is that there is general agreement that without it, VFP's RETURN TO is a flawed command, because it is incapable of adequately discriminating where to return to from the only argument it supports (a procedure name), not to mention the sheer awkwardness of constructing procedure names when we've already got an unambiguous stack depth easily obtainable. So I would still encourage MS to consider my suggesting of supporting a numeric stack depth argument to the RETURN TO command, and I'm sorry to hear that it's not a planned change for VFP7.
