Improve error messages of curses by indicating failed C function
#125843
Comments
|
That's a lot of code to carry. Do you have a use case where the you'd want to get the C function programmatically while debugging? |
|
For me no. But I felt that having the precise function that cause the exception would be worthwhile, without having to change the actual messages that were printed. I took inspiration from OSError and its filename/filename2 attributes. I think it could be useful in a debugger or to render a custom error message. Note that having the exact function is important since having the w or mw prefix may change the assumptions the caller may have. But it's really a minor feature which I found nice to have. If you think the diff is too large (and it is large because of all the small changes), we can drop it. Note that I included a minor cosmetic change where I shortened the name of some functions just for future maintenance but this commit can be dropped. |
|
But, is there a debugger that would want to add special handling specifically for |
|
Not to my knowledge. I still think it's important to know which C function was the one that returned ERR (because the name of the function in the message is not always correct IMO) but if you prefer me to update the messages instead rather than adding an attribute, I can do it. If you think we should lie (a bit) to the user then we can keep the status quo. |
|
Yes, if it's a genuine improvement, make it for everyone; change the cc @Yhg1s as the curses expert |
|
I'm back on the PR and I eventually just changed all error messages instead of adding a new class & co. |
curses C function that caused the exception as an attribute of curses.error.curses by including failed C function
curses by including failed C functioncurses by indicating failed C function
- Rename error helpers with a `curses_set_error_*` prefix instead of `PyCurses*`. - Cleanly report both NULL and ERR cases. - Raise `curses.error` in `is_linetouched` instead of a `TypeError`.
|
The rest will be addressed in #133579 |
While some `libcurses` functions are meant to return OK on success, this is not always the case for all implementations. As such, we relax the checks on the return values and allow any non-ERR value to be considered equivalent to OK.
Uh oh!
There was an error while loading. Please reload this page.
Feature or enhancement
Proposal:
The
cursesmodule raises an exceptioncurses.errorwith a message of the form "XXX() returned ERR" where XXX is generally the name of the C or Python function that was just called. Most of the time, XXX and the Python function that was called have the same name and XXX is a real curses C function or macro. However, in some cases, this is not the case and the actual curses function that was called has a different name.For debugging purposes, I suggest adding an attribute to the exception class, say
.funcnamewhich holds the name of the macro / function that was called at runtime in the C code. This will help users debug issues. For compatibility reasons, I will not change the current error messages since this could break CI in the wild. In addition, I don't expect users to extract the function name from the error message (if they want to, they should use this new attribute).I considered also adding which Python function was the bad one, but since the exception is raised from a Python function, I think it's better not to do include an other attribute. If needed, we can always add it later but for now the curses C function name is more important.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
curses.error#125844test_curses.test_attributeson x86-64 macOS #134252The text was updated successfully, but these errors were encountered: