[Python-Dev] Merging PEP 310 and PEP 340-redux?
Nick Coghlan
ncoghlan at gmail.com
Wed May 11 22:55:48 CEST 2005
Paul Moore wrote:
> At the very least, there should be a section in "rejected
> alternatives" explaining why it is not appropriate to force reraising
> of exceptions unless explicit action is taken. There could be good
> reasons (as I say, I haven't followed the discussion) but they should
> be recorded. And if there aren't any good reasons, this behaviour
> should probably be changed.
This is a good point - it's one of the things I changed in the simplification of
the semantics between 1.3 and 1.4 (previously the behaviour was much as you
describe).
The gist is that the alternative is to require an __exit__() method to raise
TerminateBlock in order to suppress an exception. Then the call to __exit__() in
the except clause needs to be wrapped in a try/except TerminateBlock/else, with
the else reraising the exception, and the except clause suppressing it. The
try/except around BLOCK1 has to have a clause added to reraise TerminateBlock so
that it isn't inadvertently suppressed when it is raised by user code (although
that may be a feature, not a bug! - I'll have to think about that one)
Basically, it's possible to set it up that way, but it was a little ugly and
hard to explain. "It's suppressed if you don't reraise it" is very simple, but
makes it easier (too easy?) to inadvertently suppress exceptions.
If people are comfortable with a little extra ugliness in the semantic details
of 'do' statements in order to make it easier to write correct __exit__()
methods, then I'm happy to change it back (I think I just talked myself into
doing that, actually).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
More information about the Python-Dev
mailing list