-
-
Notifications
You must be signed in to change notification settings - Fork 25.9k
MNT use raise from in validation.py #17545
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
Conversation
This is most certainly valuable. We should check where the pattern can be found in our codebase. I assume that we are using the @jnothman I always relied on you on these raising issues. Do you have any opinion? Maybe @thomasjpfan or @NicolasHug? |
I've been using |
Awesome. After this PR is merged, I'll create more PR(s) with the other cases. Here's a list of possible cases. Note that it may contain false positives.
|
I would prefer "raise from". I think we haven't used them everywhere because it is a Python 3 feature (and we use to support Python 2). |
@thomasjpfan Can we move this forward? |
except TypeError: | ||
raise TypeError(message) | ||
except TypeError as type_error: | ||
raise TypeError(message) from type_error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surely this should just be bare raise
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't we still want the message
to be passed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm with @NicolasHug here, the message is valuable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jnothman Nudge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the argument for keeping the bare raise
here, is that the additional message may case too much noise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have the error message in master, I see no reason to remove it now.
I'll merge the PR, @jnothman please feel free to raise any concern if any
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am happy with this change.
except TypeError: | ||
raise TypeError(message) | ||
except TypeError as type_error: | ||
raise TypeError(message) from type_error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the argument for keeping the bare raise
here, is that the additional message may case too much noise?
Thanks @cool-RR |
Sorry for my silence. Raising with the message is appropriate. Sorry for
the noise.
|
I recently went over Matplotlib, Pandas and NumPy, 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 ofraise from
tells Python to put a more accurate message between the tracebacks. Instead of this:You'll get this:
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!