[Development] Disabling exception support in QtCore?

[Olivier Goffart]

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.macieira at 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)

 -- 
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org