Support inter-thread exception handling #819
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This enables setting up custom loop properties before running the loop. This also brings various member variables and setup into a central location to make it easier to reason about and avoid possibly-None values. Tests amended. Based on an inlined version of a commit by Aman Agrawal.
This adds Controller.raise_exception_in_main_thread(), which when passed sys.exc_info() from an 'except' block in another thread raises the corresponding exception in the controller in its thread, by using an urwid watch_pipe callback to _raise_exception. Based on a form without stack trace by Aman Agrawal. Test amended.
Before this commit, exceptions in event handlers would result in a traceback overlaid on the UI (if loaded); the application could appear to continue as normal, but the event loop would fail - and identifying tracebacks was challenging, as the UI might draw over the details. This commit ensures that exceptions from event handlers are sent to the main thread in the controller, using the infrastructure added in the prior commit, where they are re-raised, causing the application to exit and the exception to be logged.
This commit adds a new boolean `critical` parameter to raise_exception_in_main_thread. If the exception event is not marked as critical then a notice popup window is shown prompting users to report the issue to #zulip-terminal or to the github issue page. If it is critical, the previous behavior is retained, ie. the exception from the other thread is raised in the main thread and the application exits. With this new parameter set to `False`, the poll_for_events loop can fail for one event (with a notice) but continue otherwise to allow the application to maintain more functionality without either abruptly exiting or not indicating that something has subtly failed.
Also explicitly return True in callback from pipe to avoid possibility of pipe removal. Test amended.
neiljp
force-pushed
the
2020-04-29-streamline-exception-handling
branch
from
35cbeb3 to
5ceef99
Compare
neiljp
added
the
PR ready to be merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This extends an approach originally in a commit by @amanagr some time ago to use an urwid pipe to allow exceptions to be passed across threads. This is a more general form which I've had in a branch for some time.
While this doesn't yet take this approach as far as it could go, this has some rather important benefits already, most noticeably if an exception occurs during event handling:
The limitations in this PR right now are: