[PyQt] Disabling qFatal on unhandled exceptions

Phil Thompson phil at riverbankcomputing.com
Thu Jul 13 22:30:02 BST 2017

On 13 Jul 2017, at 9:33 pm, Luke Campagnola <luke.campagnola at gmail.com> wrote:
> On Thu, Jul 13, 2017 at 10:47 AM, Florian Bruhin <me at the-compiler.org> wrote:
>>> 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.
>> So what are you going to do when you're in the middle of running C++
>> code and there's a Python exception? You have two choices: Either call
>> abort(), or return *some* non-sensical value (like nullptr, or 0, or an
>> empty string) to Qt, and handle the exception once you're back in
>> Python-land.
> That's true when you require a non-trivial return value from the
> python code, but slots do not have return values. It is perfectly
> reasonable to just pass the exception to sys.excepthook and move on in
> this case. Perhaps this is the source of our confusion here--in cases
> like QNetworkAccessManager::createRequest, I agree that the most
> sensible option is to abort if an exception is raised. Most of the
> time, however, python will be invoked either as a slot or as an event
> handler, neither of which (usually) has a return value.

I disagree. Most of the time Python will be invoked as a re-implementation of a C++ virtual.

The current behaviour is not going to change.


More information about the PyQt mailing list