[Development] Disabling exception support in QtCore?

Olivier Goffart olivier at woboq.com
Sat Oct 5 20:38:45 CEST 2013

On Thursday 03 October 2013 18:38:44 Thiago Macieira wrote:
> On quinta-feira, 3 de outubro de 2013 17:11:54, Alex Malyushytskyy wrote:
> > Assuming exceptions are enabled  for signal/slots what is going to happen
> > with Qt::QueuedConnection?
> > As far as I understand at this point you can't catch exception in the
> > signal.
> If we choose to standardise that exceptions are allowed from slots and they
> propagate back to the emitter, that will still only apply to direct
> connections.
> Any type of queued connection (blocking or not) is totally and utterly
> incompatible with exceptions. Throw from a slot that was called via a queued
> connection and it's now the event loop that will catch it.
> At that point we enter the other argument: are exceptions allowed to travel
> through the event loop code? If we decide that they aren't, then this is
> undefined behaviour and the application is allowed to crash.
> If we decide that they are, then the event loop will exit, returning the
> control back to the caller of exec(), potentially terminating the thread or
> the application if run() or main() don't catch it.
> > That means you will have to do it in the event loop. What is going to
> > happen next? Re-throw it and an uncaught exception again?
> > 
> > In this case I would prefer to make sure exception never leaves the slot.
> That's my argument.
> To summarise:
> 1) exceptions causing the event loop to exit do not make sense. The API to
> make the event loop to exit is quit(), not an exception. Besides, I question
> the usefulness of a global try/catch in main() or around an event loop.
> 2) given (1), exceptions must never be thrown from a slot that was called
> via QueuedConnection or BlockingQueuedConnection.
> 3) given (2), if we allowed exceptions, users would have to take care that
> they are thrown only during DirectConnection. That implies that (potentially
> other) users must know which exceptions every slot throws, so that they can
> decide whether they can connect to a given signal or connect via queued
> connections. Therefore, I would advise against this, but I will not put
> strong opposition against it.
> 4) if we decide to build QtCore with exception support after all, I would
> agree that invokeMethod() should be strongly exception-safe, though I am not
> volunteering to write that code, review it or bugfix it; though as a
> maintainer I might be called into fixing it if it falls into bitrot.
> The questions now are:
>  a) do we have volunteers to write the code, unit tests and documentation
> for direct connection slot throws, and maintain it?
>  b) is the cost worth the effort?
> To answer (b), I'd like someone to test our major platforms to see what
> happens when an exception is thrown through code built with -fno-exceptions.
> Given that the .eh_frame sections are still present, there's a chance that
> it *works*. See also -funwind-tables.

I do volounteer:
That part of the code is already exception safe so the only thing to do is to 
have the unit test.

Unit tests are there: 

For the documentation, I would refer to Mitch's old attempt.
(I presonally think this explain too much, but well)


Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

More information about the Development mailing list