gh-134170: Add colorization to unraisable exceptions #134183
Conversation
picnixz
left a comment
picnixz
left a comment
There was a problem hiding this comment.
Let's this by raising an unraisable exception inside the hook itself and check that we don't crash. I don't know if we can recursively call sys.unraisablehook because of that, but if we can, we should check that we don't segfault for whatever reason.
|
Sorry, forgot about this PR!
I think this makes sense for a follow-up, because it'll apply to the current implementation as well, right? Ideally, that test would get backported. In general, we shouldn't have to worry too much about breaking things here, because we're just adding execution of Python code to a path where you could already execute arbitrary Python code. |
Yes. |
Misc/NEWS.d/next/Core_and_Builtins/2025-05-18-10-50-46.gh-issue-134170.J0Hvmi.rst
Outdated
Show resolved
Hide resolved
Python/errors.c
Outdated
| Py_XDECREF(result); | ||
| if (result != NULL) { |
There was a problem hiding this comment.
Let's avoid checking dangling pointers. Let's do int ok = result != NULL; Py_XDECREF(result); and compare ok afterwards.
Co-authored-by: Bénédikt Tran <[email protected]>
…python into unraisable-color
Co-authored-by: Bénédikt Tran <[email protected]>
Co-authored-by: Victor Stinner <[email protected]>
Co-authored-by: Victor Stinner <[email protected]>
…4183) Default implementation of sys.unraisablehook() now uses traceback._print_exception_bltin() to print exceptions with colorized text. Co-authored-by: Bénédikt Tran <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
3 participants
It's pretty now:
I don't think it's worth it/possible to add a test for this.
sys.unraisablehook#134170📚 Documentation preview 📚: https://cpython-previews--134183.org.readthedocs.build/