_conditionally_ returning to point where exception was raised?

[Bengt Richter]

On 16 Mar 2005 09:53:11 -0800, "MackS" <mackstevenson at hotmail.com> wrote:

>Hi
>
>I'm new to Python and would like to know if the following is possible.
>
>Say I have one lower-level object A and one user-interface object B.
>Suppose B.CallingMethod() calls A.CalledMethod(), the latter method
>stumbles upon an IO error and raises an exception. The calling method
>detects the exception, but needs to get input from the user before
>deciding whether A.CalledMethod() should continue being executed or
>permantently stop/cancel the execution of the remaining code in
>A.CalledMethod(). Can this be done?
>
>What I would like to know is if the calling method is allowed to
>"decide" (at run-time) whether or not the execution of the called
>method resumes. Until now I only see two possibilities: either the
>caller is coded in a way that it handles the exception and execution of
>the called method resumes at the point where the exception was raised
>or the caller was written in a way that doesn't handle it and the
>program is stopped by the interpreter. Is there a third way, ie is it
>possible to determine at run-time whether the called method is resumed?
>
>Thanks in advance,
>
Once an exception is raised, the stack gets unwound to the point where
the exception is caught, so there is no way[1] to recover the context required
to "continue" (and eventually "return normally" as if the exception hadn't happened).

One way to preserve the stack is to call a call-back function instead of raising
an exception. Then the call-back could return some information (e.g. user input) to
the problem context to make decisions as to how to continue (or not), or the callback
itself could also raise an exception.

But then the caller has to be able to provide a call-back function one way or another.
If you are designing the whole thing, you can do it, but if you are calling low level
services that you can't change, and which raise exceptions, then you may have some
fancy wrapping to do to create your desired interface, if it is even possible.

[1] Just to note that I know it is not wise to say "no way" on c.l.py, since you never
know what clever people will come up with ;-) Maybe someone will create a way for an
exception to return a continuation object of some kind, that could optionally be called
from the exception handler to effect as-if return to the point of an exception and
continuation from there as if the exception hadn't happened (except maybe some updated
binding in the local context that could be seen by the continuing code, and be set via
the contination-object call). I have a hunch it's possible, but pretty hairy.

Regards,
Bengt Richter