QThread and implementation of notify

Question

What to look out for when reimplementing notify function in multi threaded Qt application? This is an example implementation. Currently there are no errors, but I am worried that an error could arise since multi threading in Qt uses signal slot for communication which uses notify function.

TApplication::notify(QObject *receiver, QEvent *event)
{
    bool returnValue(false);
    try
    {
        returnValue = QApplication::notify(receiver, event);
    }
    catch (IExceptionBase& e)
    {
        if (!fMain.isNull())
        {
            //report error to output and file log
        }
        else
        {
            //report error to output
        }
    }
    catch (...)
    {
        if (!fMain.isNull())
        {
            //report error to output and file log
        }
        else
        {
            //report error to output
        }
    }
    return returnValue;
}

fMain is a module with reporting functionality

jonspaceharper · Accepted Answer · 2016-07-01T17:23:42.337

2

In Qt5, this is safe. However, from the documentation, in Qt6 this will no longer work outside the main thread, and in fact, the function is being considered for deprecation in Qt6 entirely.

As Kuba Ober pointed out, reimplementing notify to catch exceptions is a bad idea, as events in other threads and any queued signals are delivered asynchronously.

edited Jul 01 '16 at 17:23

answered Jul 01 '16 at 11:30

jonspaceharper

4,207
2
22
42

Reimplementation of `notify` was done to implement a blanket "catch-all" exception sink. `postEvent` won't have anything to do with that, because the event handler doesn't execute from within it. – Kuba hasn't forgotten Monica Jul 01 '16 at 15:46
@KubaOber: Doh. The lack of a function signature and the code indentation confused me regarding the author's actual (versus stated) purpose. I will fix my answer. – jonspaceharper Jul 01 '16 at 17:20

score 2 · Answer 2 · answered Jul 01 '16 at 15:49

2

Catching all exceptions in notify is an anti-pattern. It used to be cool to do, but turned out to be a bad idea. So don't do that. If your slots or event handlers throw, wrap their code in a try-catch block. notify gives you a false sense of security because in very many cases, signals and directly-connected slots happen to be called from event handlers. But sometimes that won't be the case, and your code will crash due to an unhandled exception.

Make sure you're familiar with the Core C++ Error Handling Guidelines and C++ Exceptions and Error Handling FAQ.

answered Jul 01 '16 at 15:49

Kuba hasn't forgotten Monica

95,931
16
151
313

4

I'm going all in and reinforcing this idea: https://codereview.qt-project.org/#/c/162682/3/src/corelib/kernel/qeventloop.cpp – peppe Jul 01 '16 at 18:45
@peppe, so it's not an anti pattern to catch all exception in notify in qt5 if I use something like deleteLater, right? Then is it only way to catch exception instead of event handler? – user150497 Oct 22 '19 at 06:08
@user150497 It's not about `deleteLater` or anything else. *Don't let exceptions leave slots and event handlers.* As far as I'm concerned, Qt should detect this and fail an assertion in debug mode if that sort of abuse is perpetuated (not merely issue a warning). – Kuba hasn't forgotten Monica Oct 22 '19 at 11:51

QThread and implementation of notify

2 Answers2