[Development] Allowing event delivery prior to and after QCoreApplication

Julien Cugnière julien.cugniere at gmail.com
Tue Apr 14 19:55:47 CEST 2015


2015-04-14 16:36 GMT+02:00 Thiago Macieira <thiago.macieira at intel.com>:
>
> 2) fix it by not passing through notify() outside the main thread. That's the
> solution I implemented in I27eaacb532114dd188c4ffff13d4ad2a4bb443e6.
>

People rely on QCoreApplication::notify to provide a try/catch when
working with Qt and exceptions. That allows dealing with them in a
single place, rather than in every single function called by a Qt
event. If it stops working in threads, some applications will
definitely see the difference. They won't necessarily break, as I seem
to remember Qt has a generic try/catch around notify, but they will
loose any information from the exception.

Is it that common to destroy the application object will threads are
still delivering events ? It feels weird to me... It would be a shame
to fix a uncommon case by breaking a common one.

Just thinking out loud, but assuming it isn't that common, would it
make sense to provide a setting to choose between the two behaviors ?
Or a Qt function/slot one need to explicitly call from the most
derived application destructor when needing to continue processing
events ? Or provide a different way of creating/destroying the
application object when this behavior is required ?

Julien Cugnière



More information about the Development mailing list