Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add default GUI exception trap #1135

Merged
merged 2 commits into from
Oct 14, 2020
Merged

Conversation

fourshade
Copy link
Contributor

@fourshade fourshade commented Jul 11, 2020

When programming plugins, it's easy to write code that terminates in a fatal error if something goes wrong. Indeed, plugins might even assume that any exceptions they raise will be handled by Plover. But Qt GUI code isn't necessarily this way, since it executes one level above the engine. A GUI tool plugin that raises an exception during dialog creation, for instance, will propagate it back to MainWindow._activate_dialog, which was called by a Qt signal on clicking the toolbar button. When that exception escapes, the engine will never see it, and Plover will crash without warning.

In fact, any exception that escapes a PyQt slot will have this effect by default. Any time a slot is called from a signal, that method is the bottom of the stack as far as Python can see. If an exception escapes and sys.excepthook is not defined, Plover just crashes, but if it is defined, it executes and the event loop resumes. I have defined this function to provide a default safety net by logging any such exception as an error.

A system-wide exception hook may seem a little heavy-handed, but it's the only way to reliably catch stuff originating from arbitrary GUI plugins. The engine will still catch everything it would have caught normally; this function is only called if an exception sidesteps the engine's normal flow control by going through a Qt slot. Some debuggers like to override this hook themselves, so the hook only activates if nothing has messed with it (i.e. it is still the original value, sys.__excepthook__). Naturally, it is difficult to write tests for something this broad, but deleting random characters out of various pieces of GUI code seems to trigger it and log the error now where it would have killed Plover before. It's not something that's supposed to be executed under normal conditions in any case; it's a last resort to stop bugs in signal-based GUI code from bringing down the whole system.

Summary of changes

  • Uncaught GUI exceptions are now logged instead of crashing Plover silently.

@morinted morinted merged commit 862f60d into openstenoproject:master Oct 14, 2020
@fourshade fourshade deleted the exchook branch April 29, 2021 19:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants