[Development] Disabling exception support in QtCore?

[Thiago Macieira]

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131003/f08039d7/attachment.sig>