Fwd: Block-Scoped Exception Handlers
____def process_todo(todo):________pre_process()________for t in todo:____________except Exception, e:________________break____________process(t)________post_process()
As an alternative to ____def process_todo(todo):________pre_process()________for t in todo:____________try________________process(t)____________except Exception, e:________________break________post_process()
I don't feel former is quite readable than later. Of course, a couple `try` nested statements make the indentation worse.
For example, we wish to ignore problems in dealing with todo items, like above, but the todo items are complicated; each is a dict() of details. Failure to deal with one of the details is ignored, but the rest of the details are still attempted:
def process_todo(todo): ____pre_process() ____for t in todo: ________except Exception, e: ____________break ________for u, v in t.items(): ____________except Exception, e: ________________continue ____________process() ____post_process()
Which is better than what I do now:
def process_todo(todo): ____pre_process() ____for t in todo: ________try: ____________for u, v in t.items(): ________________try: ____________________process() ________________except Exception, e: ____________________continue ________except Exception, e: ____________break ____post_process()
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.
Realizing that the `try/finally` pair is very common leads to the creation of `with`. I am proposing the same logic for `try/catch` pair: They are commonly paired together and should have an optimized syntax.
try-catch pair shouldn't used so many like try-finally pairs.
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
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
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.
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"
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