<div dir="ltr"><span style="font-size:12.8px">Greetings,</span><div style="font-size:12.8px"><br></div><div><span style="font-size:12.8px">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:<br><br>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 </span>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. </div><div><br></div><div>2. Python should almost <i>never</i> 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--<span style="font-size:12.8px">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.</span></div><div><br></div><div>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).</div><div><br></div><div><br></div><div>Luke<br></div></div>