4 ms·

When to use "raise from None" in Python

3 points by thunderbong 2y ago

zahlman 2y ago
I already know about this construct and its purpose - but if I didn't, I would be immediately turned away by the introduction. To wit: > In Python, exceptions can be chained to provide context about what went wrong and why. This is achieved through the `raise [Exception] from [cause]` construct. While this mechanism is often helpful, it can sometimes obscure more than it clarifies. Enter raise Exception from None: a way to suppress exception chaining and simplify stacktraces for better readability. > TL;DR: > Simplify debugging: from None removes unnecessary context, making stacktraces easier to read. > Direct causation: Use it when the cause and effect are so closely linked they’re effectively the same. > Control flow: Particularly useful when exceptions are part of normal program flow or the “ask for forgiveness” pattern. This is textbook AI writing, and it's awful. The bullet points lack all sense of parallelism; the first restates something that was already in the prose summary; the third is just all kinds of awkward. If these points were meant to summarize the upcoming article, they fail at teaching effectively ("when the cause and effect" of what?); if they were meant to summarize the preceding text, they fail completely, as they have restated 56 words in 48 that take up more screen space. The overall tone is inappropriate (we're teaching programming, not presenting research) and incoherent ("TL;DR" is vastly less formal than anything in the preceding paragraph). (I also don't know how the LLM got the idea that "stack trace" should be a single word, but ew.) Here's how I might write about the subject: > It's well known that Python supports exception chaining: in an `except` block, you can `raise` a new exception `from` the original, and the result will trim the stack trace for the new exception (so it doesn't mention the work that happened in the `try` block) but also store the original exception (with its own stack trace). But did you know you can also raise an exception `from None`? This way, the stack trace for the new exception is still trimmed, but no "original exception" is chained to it. > You can use this technique to shorten and simplify your stack traces. It signals that you expect the exception to be caused by input to the current function - not by a problem encountered within the `try` block. This can make later debugging easier, by focusing your attention in the right place. > Use this technique carefully, based on your judgment of where problems are likely to actually occur - you wouldn't want to hide something useful. It's especially useful for exception handlers intended to "translate" an exception resulting from [EAFP](reference link here); in these cases, the original exception is an implementation detail of how the problem was detected - not what the problem actually is. Yes, I'm now at about 200 words instead of 100. But that isn't just the summary; it's the whole topic, modulo some code samples. This idiom really doesn't merit an entire separate 2200 word article; it should be part of a general treatment of `raise ... from ...`, or even a general treatment of Python-specific exception-handling features. (And, of course, in that context, I could write this part more succinctly.)

3 points by thunderbong 2y ago

I already know about this construct and its purpose - but if I didn't, I would be immediately turned away by the introduction. To wit: > In Python, exceptions can be chained to provide context about what went wrong and why. This is achieved through the `raise [Exception] from [cause]` construct. While this mechanism is often helpful, it can sometimes obscure more than it clarifies. Enter raise Exception from None: a way to suppress exception chaining and simplify stacktraces for better readability. > TL;DR: > Simplify debugging: from None removes unnecessary context, making stacktraces easier to read. > Direct causation: Use it when the cause and effect are so closely linked they’re effectively the same. > Control flow: Particularly useful when exceptions are part of normal program flow or the “ask for forgiveness” pattern. This is textbook AI writing, and it's awful. The bullet points lack all sense of parallelism; the first restates something that was already in the prose summary; the third is just all kinds of awkward. If these points were meant to summarize the upcoming article, they fail at teaching effectively ("when the cause and effect" of what?); if they were meant to summarize the preceding text, they fail completely, as they have restated 56 words in 48 that take up more screen space. The overall tone is inappropriate (we're teaching programming, not presenting research) and incoherent ("TL;DR" is vastly less formal than anything in the preceding paragraph). (I also don't know how the LLM got the idea that "stack trace" should be a single word, but ew.) Here's how I might write about the subject: > It's well known that Python supports exception chaining: in an `except` block, you can `raise` a new exception `from` the original, and the result will trim the stack trace for the new exception (so it doesn't mention the work that happened in the `try` block) but also store the original exception (with its own stack trace). But did you know you can also raise an exception `from None`? This way, the stack trace for the new exception is still trimmed, but no "original exception" is chained to it. > You can use this technique to shorten and simplify your stack traces. It signals that you expect the exception to be caused by input to the current function - not by a problem encountered within the `try` block. This can make later debugging easier, by focusing your attention in the right place. > Use this technique carefully, based on your judgment of where problems are likely to actually occur - you wouldn't want to hide something useful. It's especially useful for exception handlers intended to "translate" an exception resulting from [EAFP](reference link here); in these cases, the original exception is an implementation detail of how the problem was detected - not what the problem actually is. Yes, I'm now at about 200 words instead of 100. But that isn't just the summary; it's the whole topic, modulo some code samples. This idiom really doesn't merit an entire separate 2200 word article; it should be part of a general treatment of `raise ... from ...`, or even a general treatment of Python-specific exception-handling features. (And, of course, in that context, I could write this part more succinctly.)