<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt"><div style="display: block;" class="yahoo_quoted"><font face="Arial" size="2">On Thursday, October 10, 2013 9:26 AM, Olivier Goffart <olivier@woboq.com> wrote:<br> </font> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;">  <div class="y_msg_container">> On Thursday 10 October 2013 15:14:02 André Somers wrote:<br clear="none">> > Op 10-10-2013 14:53, Olivier Goffart schreef:<br clear="none">> > > On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote:<br clear="none">> > >> On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote:<br clear="none">> >
 >>>> I dislike allowing this via the signal-slot mechanism because I see<br clear="none">> > >>>> throwing from a slot as incompatible with the connection semantics.<br clear="none">> > >>>> <br clear="none">> > >>>> That would mean any signal could throw ANY exception. It would also<br clear="none">> > >>>> preempt<br clear="none">> > >>>> the execution of further slots, which might be important.<br clear="none">> > >>>> <br clear="none">> > >>>> Usually the person who connects a signal to a slot is a completely<br clear="none">> > >>>> different developer than who wrote the signal or the slot.<br clear="none">> > >>> <br clear="none">> > >>> I think your assumptions are false.<br clear="none">> > >>> When using signals and slot in an application one
 write both the signal<br clear="none">> > >>> and<br clear="none">> > >>> the slot at the same time, to wire two part of that same appliation.<br clear="none">> > >> <br clear="none">> > >> That's not at all true. If it were, we wouldn't have signals or slots in<br clear="none">> > >> our public API. If people were supposed to write the signals and the<br clear="none">> > >> slots they connect, all our signals and slots would be private.<br clear="none">> > > <br clear="none">> > > I did not said that the signal and the slot were always written by the<br clear="none">> > > same<br clear="none">> > > person.  And I explicitly said for an application, and you are talking<br clear="none">> > > about libraries.<br clear="none">> > <br clear="none">> > Even for applications this statement is nonsense. For all but
 trivial<br clear="none">> > applications that during their lifetime only get worked on by a single<br clear="none">> > developer, the likelyhood of the same person always writing the slots<br clear="none">> > for every signal goes to 0 rapidly with the age and number of developers<br clear="none">> > on a project.<br clear="none">> <br clear="none">> That's not what I said.<br clear="none"><br>It may not have been what you said, but it is what would occur.<br><br>> And regardless, I don't think it has any relevance for the problem in <br clear="none">> question.<br clear="none"><br>Quite relevant.<br> <br clear="none">> Within a code base that uses exception, developers should know which part of <br clear="none">> the code is exception safe and which part of the code can throw exception.  <br clear="none">> And they know they should not call a function that can throw an exception from <br
 clear="none">> code that is not exception safe. (Hence they don't connect a signal from code <br clear="none">> that is not exception safe to a slot that throw an exception)<br clear="none">> <br><br>So now you have to a wrapper slot to wrap exceptions for any object from a library<br>that you may interact with, or potentially any other code in your own project.<br><br>I have personnally maintained a 400k+ SLOC codebase based on QT.<br>It made extensive use of Signals/Slots between objects. Even though I was<br>pretty much the only developer working on it, I still had to quite often track<br>through signals/slots to make sure I understood things. Not because the codebase<br>was unclear, but because it was quite non-trivial. It would have been an extensive<br>PITA to try to know which ones I could or could not use exceptions with.<br><br>I'm no compiler expert - but without help from the compiler to make sure that kind<br>of things doesn't
 happen - e.g. marking signals/slots as Q_EXCEPTION_THROW<br>and Q_EXCEPTION_SAFE and having some part of the compiler chain detect<br>and at minimal warn of issues - it will not be feasible.<br><br>$0.02<br><br>Ben<br></div>  </div> </div>  </div> </div></body></html>