[PyQt] Disabling qFatal on unhandled exceptions

Luke Campagnola luke.campagnola at gmail.com
Thu Jul 13 18:16:55 BST 2017


Greetings,

I have just discovered the change to PyQt 5.5 in which unhandled exceptions
result in a call to qFatal(). Perhaps I am missing something important, but
I am a confused about why this behavior was chosen. The documentation
states that the problem with the old behavior is that "the application does
not terminate, meaning the behaviour is different to when exceptions are
raised in other situations". I have two concerns about this reasoning:

1. Unhandled exceptions in Python do not cause the program to terminate;
they only cause sys.excepthook to be invoked. The only reason some programs
exit following an unhandled exception is because the interpreter ran out of
commands to execute, and then exited gracefully. In situations where an
event loop is present, the interpreter does not run out of commands to
execute and is expected to continue processing events. This is the
consistent, expected behavior across all event loop systems I have used in
Python, including asyncio, tkinter, pygtk, tornado, twisted, gevent, PyQt4,
PySide, and Python's built-in interactive shell.

2. Python should almost *never* voluntarily abort. This is one of the most
fundamental and important differences between C++ and Python. The most
common behavior is simply to call an error handler and move on, but even in
situations where we are forced to end the process, it is dangerous to
*abort* because this circumvents all of Python's shutdown machinery--files
are not closed, destructors are not called, atexit callbacks are not
invoked. At best, this looks to the user like PyQt has caused a segfault
(except that even fauthandler will provide no useful information). At
worst, we can end up with corrupted files and possibly even damaged
hardware.

In its current state, PyQt5 stands alone among event loop systems in
deciding to shut down following an error, and it stands alone among most
(maybe all?) python modules in causing the process to abort rather than
exit cleanly. My recommendation is to revert this change as soon as
possible. If you are concerned that errors may be going unnoticed, then
consider adding a default handler that pops up a dialog for unhandled
exceptions, and add an API call to allow the user to disable it for
backward compatibility (do not rely on modifying the global sys.excepthook
to configure PyQt behavior).


Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20170713/2250e3e5/attachment.html>


More information about the PyQt mailing list