[Development] Disabling exception support in QtCore?

[Mandeep Sandhu]

On Fri, Oct 4, 2013 at 7:08 AM, Thiago Macieira
<thiago.macieira at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131004/ffce0afa/attachment.html>