On 5/12/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Steve Bethard has this example:
>
> stmt = EXPR1
> VAR1 = stmt.__enter__()
> exc = () # or (None, None, None) if you prefer
> try:
> try:
> BLOCK1
> except:
> exc = sys.exc_info()
> finally:
> if stmt.__exit__(*exc) is not None:
> raise exc[0], exc[1], exc[2]
>
> but he seems to forget that finally *always* re-raises the
> exception.
Not if except catches it:
py> try:
... try:
... raise Exception
... except:
... exc = sys.exc_info()
... finally:
... pass
...
py>
As I understand it, finally only re-raises the exception if it wasn't
already caught. And I have to use an except block above to catch it
so that sys.exc_info() returns something other than (None, None,
None).
> Anyway, I still don't care for the use case; rather than
> fixing the coding bug, your time would be better spent arguing why
> this functionality can't be missed.
Sorry, I'm unclear. Do you not want sys.exc_info() passed to
__exit__, or do you not want the with/do-statement to be allowed to
suppress exceptions? Or both?
My feeling is that the mechanism for suppressing exceptions is
confusing, and it would probably be better to always reraise the
exception. (I included it mainly to provide a middle ground between
Guido's and Nick's proposals.) That is, I prefer something like:
stmt = EXPR1
VAR1 = stmt.__enter__()
exc = () # or (None, None, None) if you prefer
try:
try:
BLOCK1
except:
exc = sys.exc_info()
finally:
stmt.__exit__(*exc)
raise exc[0], exc[1], exc[2]
which should really read the same as Guido's suggestion:
stmt = EXPR1
VAR1 = stmt.__enter__()
try:
BLOCK1
finally:
stmt.__exit__(*sys.exc_info())
except that since sys.exc_info() returns (None, None, None) when there
wasn't an except block, this won't actually work.
If we don't provide some flag that an exception occurred, the
transaction example doesn't work. My feeling is that if we're going
to provide any flag, we might as well provide the entire
sys.exc_info().
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
_______________________________________________
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
