469,275 Members | 1,709 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,275 developers. It's quick & easy.

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

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
Jul 18 '05 #1
7 1567
Michele Simionato wrote:
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.
Jul 18 '05 #2
Istvan Albert wrote:
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 ...
Jul 18 '05 #3
Michele Simionato <mi***************@gmail.com> wrote:
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
Jul 18 '05 #4
Alex Martelli wrote:
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
Jul 18 '05 #5
>>>>> "Alex" == Alex Martelli <al*****@yahoo.com> writes:

Alex> Michele Simionato <mi***************@gmail.com> wrote:
I think I want "re-entrant exceptions" (not sure if this is the Is there some elegant or hackish way to get this?


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.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #6
On 28 Sep 2004 09:17:07 -0700, mi***************@gmail.com (Michele Simionato) wrote:
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
Jul 18 '05 #7
Mathias Waack <M.*****@gmx.de> wrote:
Alex Martelli wrote:
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...


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
Jul 18 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Nel | last post: by
4 posts views Thread by Craig Bailey | last post: by
1 post views Thread by Chris | last post: by
11 posts views Thread by James | last post: by
1 post views Thread by James | last post: by
4 posts views Thread by Alan Walkington | last post: by
1 post views Thread by John Ryan | last post: by
10 posts views Thread by James | last post: by
8 posts views Thread by Beowulf | last post: by
3 posts views Thread by David Hickman | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.