On Thursday, October 10, 2013 9:26 AM, Olivier Goffart <oliv...@woboq.com> wrote: > On Thursday 10 October 2013 15:14:02 André Somers wrote: > > Op 10-10-2013 14:53, Olivier Goffart schreef: > > > 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. > > > > Even for applications this statement is nonsense. For all but trivial > > applications that during their lifetime only get worked on by a single > > developer, the likelyhood of the same person always writing the slots > > for every signal goes to 0 rapidly with the age and number of developers > > on a project. > > That's not what I said.
It may not have been what you said, but it is what would occur. > And regardless, I don't think it has any relevance for the problem in > question. Quite relevant. > Within a code base that uses exception, developers should know which part of > the code is exception safe and which part of the code can throw exception. > And they know they should not call a function that can throw an exception > from > code that is not exception safe. (Hence they don't connect a signal from code > that is not exception safe to a slot that throw an exception) > So now you have to a wrapper slot to wrap exceptions for any object from a library that you may interact with, or potentially any other code in your own project. I have personnally maintained a 400k+ SLOC codebase based on QT. It made extensive use of Signals/Slots between objects. Even though I was pretty much the only developer working on it, I still had to quite often track through signals/slots to make sure I understood things. Not because the codebase was unclear, but because it was quite non-trivial. It would have been an extensive PITA to try to know which ones I could or could not use exceptions with. I'm no compiler expert - but without help from the compiler to make sure that kind of things doesn't happen - e.g. marking signals/slots as Q_EXCEPTION_THROW and Q_EXCEPTION_SAFE and having some part of the compiler chain detect and at minimal warn of issues - it will not be feasible. $0.02 Ben
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
