>Michael,
>
>In generaly, this is the idea behind the use of RETRY and RETURN in an errorhandler.
>
>The problem is that it will be to tricky. If something reaches the general errorhandler it is called an "unexpected error".
>Even if you can return one level back, this does not mean that this level will work. If, for example, you return one level back on a funtion with expected char and return boolean, it will fail too. This is the "cascade of techy errors"
>
>Since nobody realy nows what will happen next, the only conclusion is to shut down the programm as safe as possible. This mean you need to call a handler that closes all data and shout the app dead.
>
>How safe it will be depends on the application and programming style (buffering, use of transactions etc.)
>
>Anything else would mean that the errohandler understand the prog.
>
>BTW, yes there is a bug in RETURN TO Prog eExpression. This statement should raise an compiler error.
>
>Agnes

Agnes,

If the function in question does not normally return a boolean success flag, the caller is not going to be using a construct such as IF myfunc() ... as the way of invoking it and determining its success. In any case, returning .F. instead of the default .T. isn't going to cause a type mismatch. On the other hand, if the function normally returns a non-logical type, then an error return to the caller's level could cause a mismatched type error. However, the caller in such cases can code defensively, and at worst there would be another exceptional error at the caller's level, which would trigger another error message and pop to the next level of the stack. Such secondary errors are unusual, though, because most of my functions return a boolean success flag, and I take additional precautions when calling non-trivial functions whose return value is of a different type.

There is a difference between a cascade of error messages and a cascade of failures. The initial unexpected error should produce a message, but as the failure is propagated down the stack, there needn't be any additional error messages. The caller, once informed of the function's failure can decide whether an additional message is warranted, do its usual cleanups, and return appropriately to its caller. Each level of the stack then has the opportunity to perform its own cleanups, and the ultimate result may or may not be to terminate the whole application, depending on the severity of the failure.

I don't think the "zero tolerance" philosophy of error handling that you espouse is always appropriate. Consider a complex application that runs an assemby line or a life support system. The whole system mustn't grind to a halt unless it's absolutely necessary. Of course, new modules should be tested before putting them into production, but occasionally a small bug escapes notice. A robust application that can fail gracefully doesn't shut down completely as soon as it encounters the slightest unforeseen error.

Perhaps it is an accident that the RETURN TO ... command allows passing a return value, or perhaps it is a documentation error that this feature was not mentioned. To me, it seems a lot easier to believe that someone accidentally forgot to document the feature than it is to imagine that someone accidentally went to the trouble of implementing it. It also would seem strange to support a form of RETURN statement that is incapable of specifying a return value, even though one may have legitimate need for it. Since the RETURN TO command can return to a function invocation, what sense does it make to have no control over the function return value? I really was not looking to get into that argument, so I hope you will excuse me for indulging to that extent.

Thanks for your comments.

Mike