homepage

If a context manager is used within exception handling block, the active
exception is silenced after the context block completes and __exit__ exits.
try:
 raise Exception("foo")
except:
 with SomeContextManager():
 pass
 raise # in Py2.5 throws 'foo', in Py3.0 fails with RuntimeError

This problem was introduced by r62847.

Note that the problem is not related to "with", but with nested
exception handlers:
try:
 raise Exception("foo")
except:
 try: pass
 except: pass
 raise # in Py2.5 throws 'foo', in Py3.0 fails with RuntimeError
OTOH, python has always had poor support for nested exceptions; tried
with python24 and python25::
 try:
 raise Exception("foo")
 except:
 try: raise KeyError("caught")
 except KeyError: pass
 raise # reraise the KeyError...
This does not happen if the two lines with KeyError are moved in another
function.

I've just discovered that the patch in r62847 doesn't clean up the
exception state if the except clause does not mention a local variable,
e.g. "except MyException" instead of "except MyException as e".

Raising priority.

As Amaury said, lexically nested exception handlers make re-raising
behaviour buggy. In Py3k, a workaround is to instead write:
 try:
 raise Exception("foo")
 except Exception as :
 try: raise KeyError("caught")
 except KeyError: pass
 raise e
With the slight inconvenience that the "raise e" line will be appended
to the original traceback.
If we want bare "raise" statements to work as expected after a nested
exception handler, we'll need to add proper exception stacking, for
example by adding the exception value as a member of PyTryBlock. The
effect on performance should also be measured.

Small typo in the snippet above, this should obviously read:
 try:
 raise Exception("foo")
 except Exception as e:
 try: raise KeyError("caught")
 except KeyError: pass
 raise e

Just found another funny example. This one fails also before r62847.
def except_yield():
 try:
 raise Exception("foo")
 except:
 yield 1
 raise
list(except_yield())
In Py3k (with or without r62487), we get "RuntimeError: No active
exception to reraise".
In Python 2.5, we get "TypeError: exceptions must be classes, instances,
or strings (deprecated), not NoneType".

A clean solution to both #2507 and #2833 is now proposed in #3021.

Fixed in r64121.