In some markets like Avionics and Defense, it is simply forbidden for us to use exceptions. So, at least I think it should be possible to disable them in Qt if it was decided to allow them, otherwise we would be forced to use another framework. Aside from that, and that is personal, I really like having exception free code. Signals are a much nicer alternative, AND we can run tests to see if they are all connected (again a requirement from the Avionics world: all errors must be explicitly handled). With exceptions this is much more difficult, if not impossible. Besides that, using exceptions can lead to some very strange, difficult to detect bugs, especially in applications having an event loop, and multiple threads.
So, a +1 from me to avoid exceptions. > On 04 Oct 2013, at 07:12, Mandeep Sandhu <mandeepsandhu....@gmail.com> wrote: > > >> 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
