Le 03/10/2013 10:36, Olivier Goffart a écrit : > On Wednesday 02 October 2013 09:30:58 Thiago Macieira wrote: > >> 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. This may be true in a (small) application, but definitely not if you are developping a library. Usually, you write signals but don’t have any clue about the slots that will be connected to.
>> 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. That would mean that both slots and signals needs to document which exception they can respectively throw/handle. With qt5 we gained static checking of signal/slot compatibility. Introducing exceptions here would ruin this gain, since it will introduce a new way for signal and slots to be incompatible. And i don’t know how you can reasonably catch an exception in an asynchronous call. IMHO, slots should be nothrow. >> I would accept at most exceptions through the invokeMethod mechanism in a >> DirectConnection, since that's a 1:1 relationship and there are no signals. +1. Exceptions outside DirectConnection would be very strange animals. Julien _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development