Fwd: Block-Scoped Exception Handlers
I don't feel former is quite readable than later. Of course, a couple `try` nested statements make the indentation worse.
While later is more nested, it seems straightforward. Additionally, try-catch pair should have minimum try block unlike try-finally pair. I am afraid of proposed syntax sugar misleads people to expand try block. At a high level: The `try/except/finally` is powerful structure.
When function call is very nested, only function near top level should catch Exceptions. Most of middle~bottom level functions use only finally (or with statement, off course). If many functions have catch clause, it's a very bad code smell. C# and Java have syntax sugar only for try-finally pair too. (using statement in C# and try with resource in Java). -- INADA Naoki <songofacandy@gmail.com>
On 5/6/2016 7:57 PM, INADA Naoki wrote:
If many functions have catch clause, it's a very bad code smell.
This is interesting, and the ?fourth? time it was alluded to! Maybe the lack of `try` statements is common, and people can still debug problems despite the loss of causes and stack traces. 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.
On Sat, May 7, 2016 at 9:58 AM, Kyle Lahnakoski <klahnakoski@mozilla.com> wrote:
No. Catching at near top level doesn't loss cause and stack trace. Badly wrapped exception does loss important information. It is same to multi threaded program.
On 7 May 2016 10:59, "Kyle Lahnakoski" <klahnakoski@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: https://docs.python.org/dev/library/traceback.html#stacksummary-objects Another feature potentially of interest to you is faulthandler.dump_tracebacks: https://docs.python.org/3/library/faulthandler.html#dumping-the-traceback (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 :) Cheers, Nick.
On 5/6/2016 7:57 PM, INADA Naoki wrote:
If many functions have catch clause, it's a very bad code smell.
This is interesting, and the ?fourth? time it was alluded to! Maybe the lack of `try` statements is common, and people can still debug problems despite the loss of causes and stack traces. 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.
On Sat, May 7, 2016 at 9:58 AM, Kyle Lahnakoski <klahnakoski@mozilla.com> wrote:
No. Catching at near top level doesn't loss cause and stack trace. Badly wrapped exception does loss important information. It is same to multi threaded program.
On 7 May 2016 10:59, "Kyle Lahnakoski" <klahnakoski@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: https://docs.python.org/dev/library/traceback.html#stacksummary-objects Another feature potentially of interest to you is faulthandler.dump_tracebacks: https://docs.python.org/3/library/faulthandler.html#dumping-the-traceback (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 :) Cheers, Nick.
participants (3)
-
INADA Naoki -
Kyle Lahnakoski -
Nick Coghlan