Skip to content

Add custom hooks for unraisable exceptions, to log exceptions raised in ctypes callback functions in a more readable way#16169

Merged
seanbudd merged 2 commits into
nvaccess:betafrom
lukaszgo1:I16115
Feb 13, 2024
Merged

Add custom hooks for unraisable exceptions, to log exceptions raised in ctypes callback functions in a more readable way#16169
seanbudd merged 2 commits into
nvaccess:betafrom
lukaszgo1:I16115

Conversation

@lukaszgo1

Copy link
Copy Markdown
Contributor

Opened against beta since this PR fixes regression caused by the upgrade to Python 3.11, and the change is very low risk.

Link to issue number:

Fixes #16115

Summary of the issue:

When an exception is raised in ctypes callback function Python cannot handle it in any reasonable way, so the traceback gets printed to stderr. Somewhere after Python 3.7 a change was made, so that it is printed line by line. As a result we get as many log entries as there were lines in the traceback making logging extremely noisy.

Description of user facing changes

Exceptions from ctypes callback functions once again results in a single log entry.

Description of development approach

Since Python 3.8 it is possible to customize how these so called unraisable exceptions are handle. This PR adds a handler which logs them in a readable format, mostly based on how the native Python's hook does this.

Testing strategy:

Raised an exception in winInputHook.keyboardHook, ensured it results in a single, readable log entry.

Known issues with pull request:

None known

Code Review Checklist:

  • Documentation:
    • Change log entry
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • API is compatible with existing add-ons.
  • Security precautions taken.

…in ctypes callback functions in a more readable way
@lukaszgo1 lukaszgo1 requested a review from a team as a code owner February 12, 2024 18:52
@lukaszgo1

Copy link
Copy Markdown
Contributor Author

cc @CyrilleB79

@lukaszgo1 lukaszgo1 changed the base branch from master to beta February 12, 2024 18:54
@CyrilleB79

Copy link
Copy Markdown
Contributor

Thanks for this fix @lukaszgo1!

@seanbudd seanbudd added the conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review. label Feb 12, 2024
Comment thread source/logHandler.py Outdated
@seanbudd seanbudd added this to the 2024.1 milestone Feb 13, 2024
@seanbudd seanbudd merged commit 247c974 into nvaccess:beta Feb 13, 2024
@lukaszgo1 lukaszgo1 deleted the I16115 branch February 13, 2024 06:50
Adriani90 pushed a commit to Adriani90/nvda that referenced this pull request Mar 13, 2024
…in ctypes callback functions in a more readable way (nvaccess#16169)

Fixes nvaccess#16115

Summary of the issue:
When an exception is raised in ctypes callback function Python cannot handle it in any reasonable way, so the traceback gets printed to stderr. Somewhere after Python 3.7 a change was made, so that it is printed line by line. As a result we get as many log entries as there were lines in the traceback making logging extremely noisy.

Description of user facing changes
Exceptions from ctypes callback functions once again results in a single log entry.

Description of development approach
Since Python 3.8 it is possible to customize how these so called unraisable exceptions are handle. This PR adds a handler which logs them in a readable format, mostly based on how the native Python's hook does this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Another verbose error logging issue with Python 3.11

3 participants