Support Exception-like Objects (TracebackException) For exc.__cause__ and exc.__context__

[ericsnowcurrently]

Feature or enhancement

Currently __cause__ and __context__ are expected to be exception objects (i.e. instances of BaseException). ¹ 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()²); the diff is actually relatively small
• ???

Other Notes

Prior discussion about supporting traceback.StackSummary where we currently support __traceback__: #74764 (comment)

Footnotes

1. This is just like how __traceback__ is currently expected to be a TracebackType instance. ↩

2. Since gh-110721: Use the traceback module for PyErr_Display() and fallback to the C implementation #110702 landed, we can accommodate TracebackException like this much more easily. ↩

[ericsnowcurrently]

CC @iritkatriel, @pablogsal

[iritkatriel]

Can we just make traceback.TracebackException be an Exception?

[ericsnowcurrently]

I suppose we could. That would certainly be simpler.

[ericsnowcurrently]

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]

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]

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]

Just to summarize, here are the options we've discussed so far:

1. support TracebackException-like non-exception objects in __cause__
2. make TracebackException an actual exception type
3. wrap the TracebackException object with a separate exception type (e.g. _DummyException)
4. 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]

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]

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]

I'm closing this since I don't need it or any of its variants any more.