This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients alonho, ncoghlan
Date 2012-05-31.00:15:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1338423330.58.0.79586389178.issue14963@psf.upfronthosting.co.za>
In-reply-to
Content
Sorry, I wasn't clear on what I meant by "chained correctly", and that's the part that makes this trickier than the way contextlib.nested did it. I'm referring to the __context__ attribute on exceptions that is set automatically when an exception occurs in another exception handler, which makes error displays like the following possible:

>>> from contextlib import ExitStack
>>> with ExitStack() as stack:
...     @stack.callback
...     def f():
...         1/0
...     @stack.callback
...     def f():
...         {}[1]
... 
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 243, in _invoke_next_callback
    suppress_exc = _invoke_next_callback(exc_details)
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 240, in _invoke_next_callback
    return cb(*exc_details)
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 200, in _exit_wrapper
    callback(*args, **kwds)
  File "<stdin>", line 7, in f
KeyError: 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 256, in __exit__
    return _invoke_next_callback(exc_details)
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 245, in _invoke_next_callback
    suppress_exc = cb(*sys.exc_info())
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 200, in _exit_wrapper
    callback(*args, **kwds)
  File "<stdin>", line 4, in f
ZeroDivisionError: division by zero


The recursive approach maintains that behaviour automatically because it really does create a nested set of exception handlers. With the iterative approach, we leave the exception handler before invoking the next callback, so we end up bypassing the native chaining machinery and will need to recreate it manually.

If you can make that work, then we'd end up with the best of both worlds: the individual exceptions would be clean (since they wouldn't be cluttered with the recursive call stack created by the unwinding process), but exception chaining would still keep track of things if multiple exceptions are encountered in cleanup operations.
History
Date User Action Args
2012-05-31 00:15:31ncoghlansetrecipients: + ncoghlan, alonho
2012-05-31 00:15:30ncoghlansetmessageid: <1338423330.58.0.79586389178.issue14963@psf.upfronthosting.co.za>
2012-05-31 00:15:30ncoghlanlinkissue14963 messages
2012-05-31 00:15:27ncoghlancreate