[Development] Disabling exception support in QtCore?

Kurt Pattyn pattyn.kurt at gmail.com
Thu Oct 3 12:33:40 CEST 2013


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-request at qt-project.org wrote:

> From: Julien Blanc <julien.blanc at nmc-company.fr>
> Subject: Re: [Development] Disabling exception support in QtCore?
> Date: 3 Oct 2013 11:10:21 GMT+02:00
> To: development at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131003/1996a42e/attachment.html>


More information about the Development mailing list