On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote: > On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote: > > > I dislike allowing this via the signal-slot mechanism because I see > > > throwing from a slot as incompatible with the connection semantics. > > > > > > That would mean any signal could throw ANY exception. It would also > > > preempt > > > the execution of further slots, which might be important. > > > > > > Usually the person who connects a signal to a slot is a completely > > > different developer than who wrote the signal or the slot. > > > > I think your assumptions are false. > > When using signals and slot in an application one write both the signal > > and > > the slot at the same time, to wire two part of that same appliation. > > That's not at all true. If it were, we wouldn't have signals or slots in our > public API. If people were supposed to write the signals and the slots they > connect, all our signals and slots would be private.
I did not said that the signal and the slot were always written by the same person. And I explicitly said for an application, and you are talking about libraries. > Since we have public signals and public slots and other libraries do the > same, it stands to reason that a third-party is expected to connect them. > Moreover, it stands to reason that a third-party might connect a > fourth-party slot to one of our (first-party) signals. Your logic is flawed. The fact that some signals cannot be connected to slots that do not throw exceptions does not implies that no signals can be connected to slot that throw exceptions. When developing an application, developer who throw exceptionshould know what they are doing. It is not allowed to connect a signal from a exception unsafe class to a slot that may throw exception. But if they know that the class is exception safe, it should be allowed for them to connect signal from this class to slots that throw exceptions. > > > That would mean people who do connections should have to pay attention > > > to > > > what slots throw and know what signals can cope with exceptions being > > > thrown. > > > > Signals and slots are not different from normal functions in that respect > > (especially virtual functions) > > One need to take care who calls your function when you throw exceptions. > > I agree. > > Which is why I am saying that we need to establish rules for when exceptions > would be allowed to escape a slot. > > Right now, our rule is: Qt code is noexcept. If your slot throws when called > by Qt, the behaviour is undefined. If it throws when something else calls > it, we make no statements. > > If you want to change that rule, then we can discuss it. I want to change that rule. Unles specified here, Qt code is noexcept. The only places where exceptions are allowed are: - Exceptions thrown by a slot are propagated to the signal connected with direct connection - Exceptions propagated through a call to invokeMethod are propagated from the method to the call - Exceptions thrown from QtConcurrent will be by re thrown when calling the QFuture API if the exception is a subclass of QException (Did I miss something?) -- 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