<p dir="ltr"><br>
On 7 May 2016 10:59, "Kyle Lahnakoski" <<a href="mailto:klahnakoski@mozilla.com">klahnakoski@mozilla.com</a>> wrote:<br>
><br>
> Another discussion made me realize what I am doing differently:  My problems may be unique because of multi-threaded code and logging.  I have programmed using multiple threads for a very long time, and have been catching my exceptions early-and-often so they, and their causes, are in a single structure.  My exceptions are emitted to the log (with all causes and traces) all at once or not at all.  This is necessary when multiple threads are writing to the log; writing out of order, and interlacing with other threads' log lines.  Now, I mostly write Python, but I still spawn many threads despite the GIL.  My exception handling strategy, and my logging strategy, has not changed.  <br>
><br>
> I see now.  The log generated by a single thread would be much more readable, with cause preceding effect, and without obfuscating lines from other threads.</p>
<p dir="ltr">In Python 2, you're also missing out on the ability to pass "stack_info=True" for any logging message to give it more context (although some 3rd party logging libraries may provide that).</p>
<p dir="ltr">At the very least, traceback2 backports Python 3.5's improved stack walking features, including the ability to readily extract locals from a traceback or any other frame stack: <a href="https://docs.python.org/dev/library/traceback.html#stacksummary-objects">https://docs.python.org/dev/library/traceback.html#stacksummary-objects</a></p>
<p dir="ltr">Another feature potentially of interest to you is faulthandler.dump_tracebacks: <a href="https://docs.python.org/3/library/faulthandler.html#dumping-the-traceback">https://docs.python.org/3/library/faulthandler.html#dumping-the-traceback</a></p>
<p dir="ltr">(Also available via PyPI for 2.7)</p>
<p dir="ltr">I'm not aware of any library yet that combines faulthandler's traceback dumping with traceback2's local variable capture, but that combination should be possible.</p>
<p dir="ltr">Combine that with pyrasite, and I believe it would theoretically be possible to retrieve the repr of every local variable in every currently running frame in any process you're able to attach a remote debugger to :)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>