I can add to this that Google also disallows exceptions, as is stated in their style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Exceptions#Exceptions So, Qt is not alone in this regard.
On 03 Oct 2013, at 12:00, development-requ...@qt-project.org wrote: > From: Julien Blanc <julien.bl...@nmc-company.fr> > Subject: Re: [Development] Disabling exception support in QtCore? > Date: 3 Oct 2013 11:10:21 GMT+02:00 > To: development@qt-project.org > > > 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
