Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix exception causes in web.py #2824

Closed
wants to merge 1 commit into from

Conversation

cool-RR
Copy link

@cool-RR cool-RR commented Mar 10, 2020

I recently went over Matplotlib and Pandas, fixing a small mistake in the way that Python 3's exception chaining is used. If you're interested, I can do it here too. I've done it on just one file right now.

The mistake is this: In some parts of the code, an exception is being caught and replaced with a more user-friendly error. In these cases the syntax raise new_error from old_error needs to be used.

Python 3's exception chaining means it shows not only the traceback of the current exception, but that of the original exception (and possibly more.) This is regardless of raise from. The usage of raise from tells Python to put a more accurate message between the tracebacks. Instead of this:

During handling of the above exception, another exception occurred:

You'll get this:

The above exception was the direct cause of the following exception:

The first is inaccurate, because it signifies a bug in the exception-handling code itself, which is a separate situation than wrapping an exception.

Let me know what you think!

@ploxiln
Copy link
Contributor

ploxiln commented Mar 10, 2020

For these particular simple cases, I think from None may be more appropriate.

@cool-RR
Copy link
Author

cool-RR commented Mar 11, 2020

I'm strongly against using from None. When I'm debugging, I'm like a man who got lost in the desert and is about to die of thirst. Any possible insight into what happened is like an oasis, even if there are just a few drops of water there.

Also, some tools like Django and Sentry show you all the local variables for your stacktraces, which is a godsend. These often have important information that sheds light on what went wrong, and if you remove the traceback they'll be gone.

@bdarnell bdarnell added the web label May 3, 2020
@bdarnell
Copy link
Member

I have a hard time seeing the default raise behavior as a "mistake". I agree that this change slightly improves error messages, but I don't want to take on the implied obligation to think about this as I'm writing code.

I'm also against raise from None in most cases, but if these are cases where the value of the chained exception is so small that we could even talk about getting rid of it, is it worth thinking about which of two error message variants they use?

@cool-RR
Copy link
Author

cool-RR commented Jun 19, 2020

I do think the distinction is important enough to think about, but I understand how others could disagree. As far as I'm concerned you can close this pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants