re-entering in the normal flow after an exception is raised

[Michele Simionato]

I think I want "re-entrant exceptions" (not sure if this is the
correct name).

Consider the following example:

class NotSeriousException(Exception):
pass

def do_this():
raise NotSeriousException()

def do_that():
pass

def do_this_and_that():
do_this()
do_that()

Since the exception is raised at the do_this() level, do_that() will
not be executed. However, since the exception is not that serious, I
would like to catch it and continue from the point the exception was
raised, i.e. something like that:

try:
do_this_and_that()
except NotSeriousException:
continue # does not work of course

where "continue" would continue from do_that().

Is there some elegant or hackish way to get this?
Notice that I do NOT want to modify the source code of
do_this_and_that.
It comes from real life code and I could modify it, but if there was
some
smarter way of getting what I want I would be interested ...

Michele Simionato

 

[Istvan Albert]

try:
do_this_and_that()
except NotSeriousException:
continue # does not work of course

where "continue" would continue from do_that().

Is there some elegant or hackish way to get this?
Notice that I do NOT want to modify the source code of
do_this_and_that.

Maybe you could extract the function from the current scope:

def do_this():
raise KeyError

def do_that():
return 123

def do_this_and_that():
do_this()
do_that()

try:
do_this_and_that()
except KeyError:
my_do_that = globals()['do_that']
print my_do_that()


Istvan.

 

[Istvan Albert]

Maybe you could extract the function from the current scope:

heh ... what a stupid circular logic ... since then
it would be directly available anyway ... sorry ...

 

[Alex Martelli]

I think I want "re-entrant exceptions" (not sure if this is the
correct name).

"resumable" is more common, I believe.

Is there some elegant or hackish way to get this?

I think not. You may read in Stroustrup's book about C++'s design and
evolution how he was convinced to abandon resumable exceptions by
experiences in another language, where they just didn't pay for their
huge complexity -- they seem a good idea, but don't prove to be...
they're not used often enough to justify their complexity, in practice
(designing your software well enough that exceptions do not _need_
resumption isn't that big a deal).

If something is too complicated for C++, I would assume it's WAY too
complicated for Python. So, I'm pretty happy Python's exceptions (like
C++'s, Java's, C#'s, ...) are non-resumable!


Alex

 

[Mathias Waack]

If something is too complicated for C++, I would assume it's WAY
too
complicated for Python.

It's too complicated for C++ to handle lists containing arbitrary
types, declaring functions working on arbitrary types, creating
classes at runtime...

SCNR
Mathias

 

[Ville Vainio]

Alex> I think not. You may read in Stroustrup's book about C++'s
Alex> design and evolution how he was convinced to abandon
Alex> resumable exceptions by experiences in another language,
Alex> where they just didn't pay for their huge complexity -- they
Alex> seem a good idea, but don't prove to be...

In Python they would probably be much less complex - exceptions are a
big overhead in C++ already, resumable ones would be even more so. In
python the implementation probably wouldn't be that complex and the
overhead that large.

Also, I can't help but think of the recently posted PEP 334 (Simple
Coroutines via SuspendIteration) at

http://www.python.org/peps/pep-0334.html

I probably wouldn't use resumable exceptions for normal situations
where exceptions are used, but some nice control flow hacks could be
made possible.

 

[Bengt Richter]

I think I want "re-entrant exceptions" (not sure if this is the
correct name).

As Alex said, resumable is the usual word, I think.

Consider the following example:

class NotSeriousException(Exception):
pass

def do_this():
raise NotSeriousException()

def do_that():
pass

def do_this_and_that():
do_this()
do_that()

Since the exception is raised at the do_this() level, do_that() will
not be executed. However, since the exception is not that serious, I
would like to catch it and continue from the point the exception was
raised, i.e. something like that:

try:
do_this_and_that()
except NotSeriousException:
continue # does not work of course

where "continue" would continue from do_that().

Is there some elegant or hackish way to get this?

Hacks will probably bite you later, though I think they're fine
for one-time throwaway code that you really throw away.

I wonder if you could interfere with exception unwinding via sys.settrace.
I believe you can get control at each frame as the exception propagates,
but I don't know what can be done. I think you would take a big performance hit though.

Notice that I do NOT want to modify the source code of
do_this_and_that.
It comes from real life code and I could modify it, but if there was
some
smarter way of getting what I want I would be interested ...

Maybe think about smart ways to modify?

It comes to mind that you might have functions call a complain function
instead of directly raising exceptions, if you want to customize or parameterize
by seriousness or other criteria. E.g., (untested)

def complain(kind, exc, *args):
if kind in globalconfigdict: raise exc(*args)

def dothis():
complain('not so serious', NotSeriousException, 'args', 'for', 'exception')

Just an idea. You could also make complain a callable object with various methods for
configuring behaviour easily etc. etc. Just .02USD off the top of my head ;-)

Regards,
Bengt Richter

 

[Alex Martelli]

It's too complicated for C++ to handle lists containing arbitrary
types, declaring functions working on arbitrary types, creating
classes at runtime...

Runtime creation, yes (due to C++'s choice to work with existing system
tools, chiefly the linker, and limit the language so as to make it
reasonably easy to implement on top of existing linkers) -- the other
stuff, minus the runtime part, is easily handled by templates, of
course, so it's _not_ "too complicated for C++". If you relax the
constraint on linker limitations (like just about all existing C++
implementations do), then creating and dynamically loading dynamic
libraries allows the do-it-at-runtime part just as well.

Resumable exceptions are a completely different issue from "what
capabilities can I assume in the existing system tools that I want to be
able to collaborate with".


Alex