> On Dec 14, 11:00 pm, ab <andrewb...@gmail.com> wrote:
>>> `wrap_and_raise()` will appear in the traceback, `raise
>>> wrap_exception(SomeException())` would be cleaner.
>> I like that
> But you must use the three-argument `raise` statement to supply your
> own traceback in Python 2.x. You could dispense with the function
> entirely if you're happy to repeat `import sys; raise NewException(),
> None, sys.exc_info()` instead--although then you lose some
> information, see below.
I pictured the solution to be closer to PEP 3109 / Java: The wrapped
exception as an attribute on the new exception, with the traceback
attached in `exp.__cause__.__traceback__`. That's where my
`WrappingException(.., wrap=True)` came from.
I don't like the mangled tracebacks, but you're right - the reference
cycle-free python 2.x solution probably is to use the tree-argument
>>> Your patch seems to swallow the new exception's traceback now
>>> of the causing traceback. That might be good in some situations, but
>>> generally both should be preserved.
> No; the only part of the traceback lost is the `raise` line within
> `wrap_and_raise`; the remainder of the traceback which would
> correspond to all but the `raise` line of the new exception's
> traceback is preserved. But if you weren't using the `wrap_and_raise`
> function, you would lose the line of the traceback where the new
> exception was raised. Put the following code in a python script and
> compare the tracebacks when it calls wrapped(), unwrapped(), or
My mistake, of course you're right.