_conditionally_ returning to point where exception was raised?

[MackS]

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,

Mack Stevenson

 

[infidel]

There's no "Resume Next" in python. Once you catch an exception, the
only way you can go is forward from that point.

So if B.CallingMethod catches an exception that was raised in
A.CalledMethod, all it could do is try calling A.CalledMethod again, it
can't jump back to the point where the exception was raised. About the
best you could, I think, would be to break A.CalledMethod up into
smaller function and let B.CallingMethod call each one in sequence,
deciding whether or not to continue if an exception is raised in any of
them.

 

[Bengt Richter]

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

 

[Skip Montanaro]

Bengt> Once an exception is raised, the stack gets unwound to the point
Bengt> where the exception is caught, so there is no way[1] to recover
Bengt> the context required to "continue" (and eventually "return
Bengt> normally" as if the exception hadn't happened).

I suspect in the OP's case if A.CalledMethod hasn't gone too far before
encountering an IOError it's quite reasonable to thing that B.CallingMethod
just call A.CalledMethod again if it decides to continue.

I will point out that someone posted some "autoload" code here awhile ago
(who was it?) to try to import missing modules. I use a variant in my
Python startup file:

% python
Python 2.5a0 (#75, Mar 15 2005, 21:55:51)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information. found sin in math module
-0.958924274663 <function Connect at 0x136abb0>

After finding the module that needs to be imported, it reexecutes the code
object for the frame where the exception was raised:

exec import_stmt in f_locals, f_globals
exec tb.tb_frame.f_code in f_locals, f_globals

That's not exactly what the OP asked for (it executes the code object from
the beginning, not from the point where the exception was raised with
possibly modified locals and globals), but might provide people with some
ideas. The full autoload module is at

http://manatee.mojam.com/~skip/python/autoload.py

Skip