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 bpo-2507 and bpo-2833 is now proposed in bpo-3021.

Fixed in r64121.