| msg76732 - (view) |
Author: Alyssa Coghlan (ncoghlan) *  |
Date: 2008-12-02 10:33 |
| The interactive interpreter doesn't appear to like it if __cause__ and __context__ are both set on the current exception. ================= >>> try: ... raise IOError ... except: ... raise AttributeError from KeyError ... KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 2, in IOError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 4, in AttributeError ================= I'm not entirely sure what *should* be displayed here (the code I typed in is admittedly bizarre), but what is currently being displayed definitely isn't right. |
|
|
| msg76733 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2008-12-02 10:35 |
| Such a bizarre corner case probably isn't an actual release blocker, but I'm setting it as such so that Barry can make that call explicitly before the final 3.0 release. |
|
|
| msg76746 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-12-02 14:33 |
| The current behaviour is the result of how I interpreted the error reporting specification in PEP 3134. See "Enhanced Reporting" in http://www.python.org/dev/peps/pep-3134/ . I may have misinterpreted it, in that both the cause and the context are printed out while the PEP may be read as suggesting the context must not be printed out when there is a cause. In any case, I don't think it is a release blocker. It only regards a new and advanced feature (explicit exception chaining) and doesn't disrupt its functioning. |
|
|
| msg76775 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2008-12-02 20:22 |
| This looks like it only affects printing exceptions with implicit chaining when the exception propagates to the top level. (Maybe it also affects the traceback module?) In that case, I agree with Antoine. Let's fix it in 3.0.1. |
|
|
| msg76780 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2008-12-02 20:49 |
| Note that the display is correct in the case where the chaining is "right", i.e.: try: raise IOError except: try: raise KeyError except Exception as ex: raise AttributeError from ex In that case, IOError is correctly flagged as the original exception, with a KeyError then occurring during the IOError handling, and the KeyError then directly causing the AttributeError. The weird thing I am doing in the example here is to set the __cause__ of the exception I am raising to an exception that was never itself actually raised (the "from KeyError" bit). |
|
|
| msg76786 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2008-12-02 21:17 |
| Looks to me like the display code is getting confused by the lack of a non-None __context__ on the KeyError. Perhaps the "raise ex from cause" syntax should be setting the __context__ on the "cause" exception if it isn't already set? Or else we could just special case this kind of weird programmer behaviour in the display code. ======================= >>> try: ... raise IOError ... except Exception as ex: ... ke = KeyError() ... ke.__context__ = ex ... raise AttributeError from ke ... Traceback (most recent call last): File "", line 2, in IOError During handling of the above exception, another exception occurred: KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 6, in AttributeError ======================= |
|
|
| msg77931 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-12-16 20:45 |
| Here is a patch. Should it go in? |
|
|
| msg95423 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2009-11-18 12:04 |
| Reviewed patch diff - looks good to me. It's an obscure corner case, but the patch is pretty straightforward so we may as well clean it up. |
|
|
| msg95793 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-11-28 16:16 |
| Finally committed in py3k and 3.1. Thanks! |
|
|