On Sun, Nov 14, 2010 at 1:40 PM, R. David Murray <rdmur...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
