Repository navigation
Improve error messages of curses by indicating failed C function #125843
Description
Activity
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
curses.error?
If not, I recommend to drop this.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.
I'm back on the PR and I eventually just changed all error messages instead of adding a new class & co.
- changed the title
[-]Expose the name of the `curses` C function that caused the exception as an attribute of `curses.error`.[/-][+]Improve error messages of `curses` by including failed C function[/+]on Apr 26, 2025 - changed the title
[-]Improve error messages of `curses` by including failed C function[/-][+]Improve error messages of `curses` by indicating failed C function[/+]on Apr 26, 2025
Metadata
Metadata
Assignees
Projects
- Status
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 #134252