ENH: Restore TypeError cleanup in array function dispatching#23659
Conversation
When the dispathcer raises a TypeError and it starts with the dispatchers name (or actually __qualname__ not that it normally matters), then it is nicer for users if we just raise a new error with the public symbol name. Python does not seem to normalize exception and goes down the unicode path, but I assume that e.g. PyPy may not do that. And there might be other weirder reason why we go down the full path. I have manually tested it by forcing Normalization. Closes numpygh-23029
Not that it mattered, but docs say direction should be either -1 or 1
| if (message == NULL) { | ||
| goto restore_error; | ||
| } | ||
| PyErr_SetObject(PyExc_TypeError, message); |
There was a problem hiding this comment.
What happens to the original error?
There was a problem hiding this comment.
The message was mutated, the original error/traceback is assumed to be irrelevant (i.e. something like TypeError: _median() doesn't have a keyword argument '...' when it should be median().
There was a problem hiding this comment.
I'm probably confused here, but isn't the original error still there and this sets a new error?
There was a problem hiding this comment.
PyErr_Fetch clears the original error. Although I think PyErr_SetObject would do so also if the error was still in progress.
There was a problem hiding this comment.
PyErr_Fetchclears the original error.
Ah, that is what I was missing.
|
The reference counting here is a tangle :) |
|
Thanks Sebastian. |
2 participants
When the dispatcher raises a TypeError and it starts with the dispatchers name (or actually qualname not that it normally matters), then it is nicer for users if we just raise a new error with the public symbol name.
Python does not seem to normalize exception and goes down the unicode path, but I assume that e.g. PyPy may not do that. And there might be other weirder reason why we go down the full path. I have manually tested it by forcing Normalization.
Closes gh-23029