[Python-3000] Exception re-raising woes

Antoine solipsis at pitrou.net
Mon May 26 18:48:54 CEST 2008


Hi,

>> The only slight annoyance being that the re-raising statement
>> ("raise e") is added at the end of the original traceback.
>
> I wouldn't call that either "incorrect" or "non-obvious".

What are you talking about exactly? :)
The fact that in 2.x the last caught exception is re-raised even after the
end of the except block which caught it, rather than the exception caught
by the lexically enclosing block?

Anyway, in 3.x this behaviour will be impossible to mimick, since by
specification the exception state must disappear at the end of the except
block.

> That seems like an awful lot of work and change just to trade the above
> problem for a new one:
>
>     try:
>        raise Exception("foo")
>     except Exception as e:
>        try: raise KeyError("caught")
>        except KeyError as x: pass
>        raise x

The snippet above will not work under 3.x *by design* (the "x" variable
disappears at the end of the except block), there is even a test for it in
test_exceptions.py :-)

The proposal I made is meant to allow having proper exception cleanup
semantics as mandated by the py3k spec, and yet be able to using a bare
"raise" re-raising statement in non-trivial nested exception handler
situations.

Or of course we can just decide that bare "raise" is obsolete in 3.x and
must be replaced with a properly qualified raise statement.

Regards

Antoine.




More information about the Python-3000 mailing list