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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
