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: https://codereview.qt-project.org/67361 https://codereview.qt-project.org/67362 For the documentation, I would refer to Mitch's old attempt. https://codereview.qt-project.org/41179 (I presonally think this explain too much, but well) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development