[Python-ideas] Fwd: Block-Scoped Exception Handlers

Nick Coghlan ncoghlan at gmail.com
Sat May 7 09:31:20 EDT 2016

On 7 May 2016 10:59, "Kyle Lahnakoski" <klahnakoski at mozilla.com> wrote:
> 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.
> 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.

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).

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:

Another feature potentially of interest to you is

(Also available via PyPI for 2.7)

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.

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 :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160507/e5fbd30c/attachment-0001.html>

More information about the Python-ideas mailing list