-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
bpo-45711: use exc_value instead of exc_type to determine if exc_info is valid. Add more assertions. #29627
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
bpo-45711: use exc_value instead of exc_type to determine if exc_info is valid. Add more assertions. #29627
Conversation
…engthen redundancy assertion for NULL/None.
🤖 New build scheduled with the buildbot fleet by @iritkatriel for commit bc889bc 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
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 noticed that in some places you require type and value to be both "nullish" or both "not nullish" (where "nullish" means either NULL or Py_None), and in other places (in particular in _assert_exception_type_is_redundant()
) they are required to both be the same nullishness (i.e., both NULL or both Py_None or neither of them nullish). Is there a reason for the difference?
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
Yes. Most of these assertions are verifying that the change right next to them is valid. So if I replace |
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.
Okay, I'm through now. (Sorry for the premature send on the first batch.)
Python/errors.c
Outdated
@@ -586,7 +633,18 @@ _PyErr_ChainStackItem(_PyErr_StackItem *exc_info) | |||
exc2 = exc_info->exc_type; |
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.
While you're here could you change 'exc' and 'exc2' to 'type' and 'type2' (or 'typ' and 'typ2')? It drives me nuts that we mix "exc[exption]" and "typ[e]" for the same concept (this must date back to Python 1 when the value was not an exception instance and the exception could be any object).
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.
All good! (Alas, I'm still stuck trying to wrap my head around the except*
implementation, so that one will probably have to wait until next week.)
… is valid. Add more assertions. (pythonGH-29627)
This brings us closer to removing exc_type from exc_info.
Where exc_type is used, I made it use exc_value instead and added assertions that this is ok. Then when we remove exc_type it will just be a matter of removing the assertions.
https://bugs.python.org/issue45711