[Python-Dev] unexpected traceback/stack behavior with chained exceptions (issue 1553375)

[Nick Coghlan]

On Sun, Nov 14, 2010 at 1:40 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> Issue 1553375 [1] proposes a patch to add an 'allframes' option to the
> traceback printing and formatting routines so that the full traceback
> from the top of the execution stack down to the exception is printed,
> instead of just from the point where the exception is caught down to
> the exception.  This is useful when the reason you are capturing the
> traceback is to log it, and you have several different points in your
> application where you do such traceback logging.  You often really want
> to know the entire stack in that case; logging only from the capture
> point down can lose important debugging information depending on how
> the application is structured.
>
> The patch seems to work well, except for one problem that I don't have
> enough CPython internals knowledge to understand.  If the traceback we
> are printing has a chained traceback, the resulting full traceback shows
> the line that is printing the traceback instead of the line from the 'try'
> block.  (It prints the expected line if there is no chained traceback).
>
> So, is this a failure in my understanding of how tracebacks are supposed
> to work, or a bug in how chained tracebacks are constructed?

It looks to me like you're grabbing a reference to a frame that is
currently executing and that frame has moved on since the exception
was thrown (to your exception handler). The print_stack() call in the
patch then accurately reflects this.

The other thing to keep in mind is that the exception currently being
handled is the *last* one produced by _iter_chain - all of the rest
have already been caught and handled, it was the handlers for those
that raised the subsequent exceptions in the chain.

Basically, the whole patch strikes me as fundamentally misguided. If
someone wants this information in their exception handler, they should
put a print_stack() with the appropriate header information after the
print_exception() call rather than trying to embed it in the display
of the exception information. logging could also gain an independent
"stack_trace=True" option to request inclusion of a stack trace
independently of whether or not exception information is included.

(Side note: there's a typo in the format_tb docstring claiming it is a
wrapper around extract_stack - that's incorrect, it is a wrapper
around extract_tb)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia