[issue2833] __exit__ silences the active exception

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Fixed in r64121. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> __

[issue2833] __exit__ silences the active exception

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- superseder: -> Lexical exception handlers ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2833] __exit__ silences the active exception

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: A clean solution to both #2507 and #2833 is now proposed in #3021. ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2833] __exit__ silences the active exception

Changes by Adam Olsen <[EMAIL PROTECTED]>: -- nosy: +Rhamphoryncus ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list maili

[issue2833] __exit__ silences the active exception

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: 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 "Runtime

[issue2833] __exit__ silences the active exception

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: 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 __ Trac

[issue2833] __exit__ silences the active exception

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: 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 Key

[issue2833] __exit__ silences the active exception

Georg Brandl <[EMAIL PROTECTED]> added the comment: Raising priority. -- nosy: +georg.brandl priority: -> release blocker __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2833] __exit__ silences the active exception

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: 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". __ Trac

[issue2833] __exit__ silences the active exception

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: 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, pytho

[issue2833] __exit__ silences the active exception

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: -- nosy: +pitrou __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue2833] __exit__ silences the active exception

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: This problem was introduced by r62847. -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> __ __

[issue2833] __exit__ silences the active exception

New submission from Dmitry Dvoinikov <[EMAIL PROTECTED]>: 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 r