On 2/7/2020 11:08 PM, Andrew Barnert via Python-ideas wrote:
On Feb 7, 2020, at 16:11, Steven D'Aprano <steve@pearwood.info> wrote:
Shai Berger wants to set it implicily, based on where the raise is. If it is "directly" under the except line, implicitly set the cause.
It seems like a truly bad idea to change the semantics of the exception depending on which of these I happen to write:
# exception with __cause__ magically set except ZeroDivisionError: raise ValueError(generate_long_exception_text())
# exception with __context__ set but not __cause__ except ZeroDivisionError: msg = generate_long_exception_text() raise ValueError(msg) I interpreted “directly under” as meaning “directly lexically contained by”, not “on the next physical line”. And even if that isn’t what Shai meant, it’s what I meant. :)
So both of these are the same case. The different case is where you call some function (or use some operator or syntax) that raises, instead of using a raise statement. Which I thought would have been obvious from the examples, but I guess not, so… now hopefully it’s clear?
The idea is that when you explicitly raise, that’s probably because you wanted to raise, and that’s obvious to anyone reading your code, but when you called log and it happened to raise because you’re shutting down and the log file no longer exists, that’s probably an error.
I’m not sure it is worth distinguishing these cases in the first place, but if it is, I think Shai’s idea (or mine, if I misinterpreted Shai’s) might be a decent match, and very simple.
I'm -1 on this for several reasons, but the biggest is that if you refactored the code to call a function to handle the exception, you'll change the exception chaining. Erc