On Fri, Oct 4, 2013 at 7:08 AM, Thiago Macieira <thiago.macie...@intel.com>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. > > +1 to that. Though my opinion is that if we _have_ to have exceptions then don't make exceptions to where they can apply (pun intended!:)), like only to signal-slots that too with DirectConnection, otherwise it starts looking like a 'caveat' that users must remember. If possible, it should be either ALL or nothing. Also, is it so difficult to write code which is a mix of both, i.e interacting with libs which have exceptions and also with those that don't? I bet there's already a lot of s/w out there that uses libraries written by ppl from these 2 different schools of thought. (I've mostly been a "user" of Qt and have written my applications on embedded systems w/o feeling the need for exceptions, though my opinion might be biased as I came from a C programming background where we were used on the good ol' way of checking return values of fxns) -mandeep
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development