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.

Title: let exception react to being raised or the setting of magic properties (like __cause__) within Python
Type: enhancement Stage: resolved
Components: Versions: Python 3.6, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: abathur, iritkatriel, r.david.murray
Priority: normal Keywords:

Created on 2015-04-09 20:18 by abathur, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (6)
msg240377 - (view) Author: Travis A. Everett (abathur) Date: 2015-04-09 20:18
I've been working on a testing tool which raises its own exceptions from those thrown by code under test. The tool's exceptions do some analysis to categorize and add additional information to the underlying exceptions, and they need access to the __cause__ property in order to build this information.

Unfortunately, because the __cause__ property isn't available on the exception objects at init time, some number of workarounds must be employed which make the exception harder to use properly and code handling it less intuitive. While the workarounds are fine at the moment, it would be ideal if the exceptions could be notified instead of burdening the site of each use with workarounds.

It seems sufficient to call a magic method on the exception immediately after these the traceback/cause/context parameters have been set while it is being raised, allowing the exception to perform any essential work. A bells-and-whistles implementation might be a magic method called at raise time with all of these properties as arguments (and the responsibility to deal with them)--but I assume there are reasons exception objects don't already have this level of control.
msg240379 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-04-09 20:22
Can't you use a __setattr__ hook?  Your use case seems pretty specialized.
msg240426 - (view) Author: Travis A. Everett (abathur) Date: 2015-04-10 15:38
I attempted to intercept the set with both a property setter and __setattr__ with no luck.

I agree the use-case feels pretty specialized (at least to me). I'm not familiar with Python's source, but as best as I can tell these magic properties get set in the C source in such a way that the changes can't be observed through the typical Python interfaces.
msg240428 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-04-10 15:57
oh, yes, that makes sense.  I think you'd need to bring this up on python-ideas to see if people think it is a worthwhile feature, but I suspect the answer is going to be no, it is too specialized.   On the other hand, the asyncio folks have run into some limitations in python exception handling, so it is possible there might be some cross-fertilization there.
msg404549 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-10-21 00:01
> It seems sufficient to call a magic method on the exception immediately after these the traceback/cause/context parameters have been set while it is being raised

What should happen if this callback raises an exception?
msg409463 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2022-01-01 15:08
I think this proposal should be rejected. We cannot safely pass control back to python code in the midst of raising an exception.
Date User Action Args
2022-04-11 14:58:15adminsetgithub: 68090
2022-01-10 23:15:16iritkatrielsetstatus: pending -> closed
stage: resolved
2022-01-01 15:08:39iritkatrielsetstatus: open -> pending
resolution: rejected
messages: + msg409463
2021-10-21 00:01:46iritkatrielsetnosy: + iritkatriel
messages: + msg404549
2015-04-10 15:57:16r.david.murraysetmessages: + msg240428
2015-04-10 15:38:56abathursetmessages: + msg240426
2015-04-09 20:22:34r.david.murraysetnosy: + r.david.murray
messages: + msg240379
2015-04-09 20:18:28abathurcreate