On 02.10.13 09:09, "Olivier Goffart" <oliv...@woboq.com> wrote:
>On Tuesday 01 October 2013 23:32:00 Thiago Macieira wrote: >> On quarta-feira, 2 de outubro de 2013 05:42:24, Knoll Lars wrote: >> > On 01.10.13 23:23, "Thiago Macieira" <thiago.macie...@intel.com> >>wrote: >> > >On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: >> > >> Yes, signal/slot connections between user code should IMO still be >>able >> > >> to pass through exceptions. I am afraid removing that will break >>code >> > >>that's out there. >> > > >> > >This is already forbidden since 5.0. >> > >> > Is there any good reason why we don't support this, as we did in Qt >>4? My >> > goal of still compiling Qt Core with exceptions enabled was to allow >>for >> > exactly this use case. >> >> Because we don't test it, so there's no guarantee that it works. In >>fact, >> I'd be surprised if it works at all. What's more, our types aren't >> exception-safe, even the container types. It's entirely unknown what >>will >> happen during a stack unwind. >> >> Personally, I don't want to maintain that functionality. >> >> And then there's the question: is it worth the 7% increase in code size? > >It is working. We even got bug report for some corner case where it did >not, >and I fixed those. (so they are used) >There is no test because you did not want to have one. But we could >easily add >more auto tests. (It is really not that difficult) >And it is "forbidden" only because you decided so, but it is not actually >forbidden. > >I personally think letting exception go from the slot to the signal is a >good >feature (for the DirectConnection case). >I am willing to maintain this functionality. > >Of course it is not allowed to throw an exception with QueuedConnection, >or if >the caller of the signal is not exception safe (all signals in Qt). >And if a signal is connected to several slots, further slots are not >going to >be called. > >The only stack frame it needs to crosses are QMetaObject::activate, the >moc >generated code for signals or qt_metacall, and the templated helpers in >qobject(defs)_impl.h. Could we perhaps only compile part of QtCore with >exception support? > >Exceptions are not only about std::bad_alloc. >I think it is unfortunuate that we removed support for user thrown >exceptions >from our container. (I agree that supporting bad_alloc is useless). >But supporting throwing constructor and copy constructor in all the >containers >is a bit harder than in signals and slots. (And also less usefull) +1. It's our decision not to use exceptions in Qt code, but I see quite a bit of value in being able to throw exceptions from a slot if that's the pattern a developer chooses to use. We've been doing quite a bit of work to allow this in Qt 4, and it's the main place where exception safety in Qt Core really makes sense IMO. Cheers, Lars _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
