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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development