GeezerVison is showing github.com — Support Exception-like Objects (TracebackException) For exc.__cause__ and exc.__context__ · Issue #111921 · python/cpython
Support Exception-like Objects (TracebackException) For exc.__cause__ and exc.__context__ #111921DescriptionFeature or enhancement
Currently __cause__ and __context__ are expected to be exception objects (i.e. instances of BaseException). 1 We don't always enforce this expectation, but we definitely do in some places.
Proposal
I'd like to allow them to be non-exception objects, as long as the objects look like exceptions. My own interest is that I be able to set either attribute to traceback.TracebackException objects specifically. However, I expect that supporting them would in practice mean supporting any object that matches the appropriate drop-in-replacement interface. [^2]
[^2] See gh-111917.
Note that I am not suggesting that we be able to use such drop-in-replacements anywhere the runtime expects exception objects. You couldn't start raising TracebackException objects nor catch them I don't have any motivating case for any of that. I'm only suggesting support in __cause__ and __context__.
drop-in-replacement for exception objects
The idea of drop-in-replacement (proxy or not) for an exception object isn't mine alone. The implication of the traceback.TracebackException docs is that it may be used as a representative proxy of an exception object. Furthermore, there has already been some consideration for treating TracebackException as a drop-in-replacement in actual technical situations, e.g. when pickling: #73652 (comment).
What would need to happen?
How are __cause__ and __context__ used (or might be used)?
sys.excepthook()- introspection
- (hypothetical?) raised directly after handling an exception
- ???
What would have to change?
- update
TracebackException appropriately (it is used for the default sys.excepthook()2); the diff is actually relatively small
- ???
Other Notes
Prior discussion about supporting traceback.StackSummary where we currently support __traceback__: #74764 (comment)
Activityericsnowcurrently commented on Nov 9, 2023 iritkatriel commented on Nov 9, 2023 Can we just make traceback.TracebackException be an Exception? ericsnowcurrently commented on Nov 9, 2023 I suppose we could. That would certainly be simpler. ericsnowcurrently commented on Nov 18, 2023 Having thought about it, the thing I don't like about subclassing Exception is that then people could start raising TracebackException, which seems like a strange thing. Things get weird when __cause__, __traceback__, etc. might end up getting overwritten. It would be less of an issue if TracebackException were a read-only snapshot. Regardless, maybe mutability and raising isn't such a big deal.
Another option: support a new attr (something like __remote_cause__) for the traceback module to use in cases like subinterpreters where the exception we want to display simply does not exist. The value would be an object that matches TracebackException's API:
.format().format_exception_only().print() iritkatriel commented on Nov 18, 2023 There might be a third option:
Instead of making TracebackException extend Exception, define an exception type that wraps a TracebackException. Then if the wrapper gets raised, it doesn't trample on the data in the wrapped TracebackException. ericsnowcurrently commented on Nov 20, 2023 I'm glad you brought this up because I had the same idea. Last week I actually spent some time trying out a dedicated exception that wraps TracebackException, which I named _DummyException. My conclusion is that it would work but there's something that feels slightly off about it. Mainly, this would require a new TracebackException.__new__() to return the wrapped object, which would mostly mean throwing away the dummy exception's info (e.g. traceback, cause). For my use case that isn't a big deal, but if folks started using the dummy directly then it could easily get confusing. I'm apprehensive about opening that door...
...which is why I thought of __remove_cause__. That feels like a very natural, clean, and clear solution. However, it has its own problem: adding a new "dunder" attribute to exceptions, even if only optional, feels like serious overkill. ericsnowcurrently commented on Nov 20, 2023 Just to summarize, here are the options we've discussed so far:
- support
TracebackException-like non-exception objects in __cause__
- make
TracebackException an actual exception type
- wrap the
TracebackException object with a separate exception type (e.g. _DummyException)
- like (1), but in a new
__remote_cause__
Each of (1)-(3) has awkward potential corner cases and some awkward conceptual weirdness. I'd strongly favor (4) if it didn't feel so heavy-handed. ericsnowcurrently commented on Nov 20, 2023 Another idea:
Ditch the generalized solution and deal with it via the specific exception (like we do with ExceptionGroup). That could involve using __notes__ or the exception's __repr__(). iritkatriel commented on Nov 20, 2023 I think __repr__ is better than __notes__, because notes are supposed to be for where the exception needs to be enriched with more information after it was created, and that's not what's happening here. ericsnowcurrently commented on Nov 28, 2023 I'm closing this since I don't need it or any of its variants any more.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|