Message268467
| Author |
ncoghlan |
| Recipients |
Rotem Yaari, Yury.Selivanov, georg.brandl, gregory.p.smith, gvanrossum, larry, ncoghlan, oconnor663, serhiy.storchaka, vstinner, yselivanov |
| Date |
2016年06月13日.19:52:50 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1465847570.94.0.78179897347.issue25782@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
For both of the proposed patches, could we add a test case based on contextlib.ExitStack and a variant of Victor's #27122 reproducer script at http://bugs.python.org/file42999/hang_bug2.py that uses a deliberately broken __exit__ implementation that always re-raises the exception thrown into the underlying generator?
As discussed on that issue, I'm wondering if we need some additional defensive coding in ExitStack itself, or if resolving this underlying problem will be enough to also categorically prevent the hang in ExitStack.
As far as possible resolutions go, I tend to prefer lying about the shape of the exception state over changing the type of the raised exception - we already know the true exception state is a tree rather than a chain (see #18861 for some related discussions), and we should be able to ensure that all active exceptions remain somewhere in the chain, even if their order is a bit surprising. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2016年06月13日 19:52:50 | ncoghlan | set | recipients:
+ ncoghlan, gvanrossum, georg.brandl, gregory.p.smith, vstinner, larry, Yury.Selivanov, serhiy.storchaka, yselivanov, oconnor663, Rotem Yaari |
| 2016年06月13日 19:52:50 | ncoghlan | set | messageid: <1465847570.94.0.78179897347.issue25782@psf.upfronthosting.co.za> |
| 2016年06月13日 19:52:50 | ncoghlan | link | issue25782 messages |
| 2016年06月13日 19:52:50 | ncoghlan | create |
|