>> However, someone who is using currently exceptions, they will have to
change
their code for more complicated code because we decided to forbid it ("for
their own good")
>> May I recall that exceptions through signals and slots always worked,
and was
used.
It never worked.with other than direct connections.
As I see it there is a simple choice either to provide indirect connections
or propagate exceptions to signal.
Otherwise you always have to assume that every slot is called the way you
can't let exception leave slot anyway.
Alex
On Thu, Oct 10, 2013 at 9:46 AM, Knoll Lars <lars.kn...@digia.com> wrote:
> On 10/10/13 6:02 PM, "Olivier Goffart" <oliv...@woboq.com> wrote:
>
> >On Thursday 10 October 2013 08:22:44 BRM wrote:
> >
> >> I have personnally maintained a 400k+ SLOC codebase based on QT.
> >> It made extensive use of Signals/Slots between objects. Even though I
> >>was
> >> pretty much the only developer working on it, I still had to quite often
> >> track through signals/slots to make sure I understood things. Not
> >>because
> >> the codebase was unclear, but because it was quite non-trivial. It would
> >> have been an extensive PITA to try to know which ones I could or could
> >>not
> >> use exceptions with.
> >>
> >> I'm no compiler expert - but without help from the compiler to make sure
> >> that kind of things doesn't happen - e.g. marking signals/slots as
> >> Q_EXCEPTION_THROW and Q_EXCEPTION_SAFE and having some part of the
> >>compiler
> >> chain detect and at minimal warn of issues - it will not be feasible.
> >
> >
> >Programming is not easy.
> >Now, our goal is to make programming with Qt as easy as possible.
> >
> >Tell me what makes programming easier:
> >
> >1) We forbid any use of exception in any slot connected to any signal.
> > - Programmers that don't use exceptions don't care because it does
> >not
> >impact them.
> > - Programmers that uses exception in their application to forward
> >errors
> >cannot use signals and slots to propagate exceptions from one object of
> >their
> >application to another anymore.
> >
> >2) We allow slots to forward the exception to the signal.
> > - Programmers that don't use exceptions still don't care because it
> >does
> >not impact them.
> > - Programmers that use exceptions can hapilly let exceptions go from
> >the
> >slot to where the signal is emitted.
> >
> >
> >If you are not using exception now as I understand from your text above,
> >then
> >nothing changes for you.
> >
> >However, someone who is using currently exceptions, they will have to
> >change
> >their code for more complicated code because we decided to forbid it
> >("for
> >their own good")
> >
> >May I recall that exceptions through signals and slots always worked, and
> >was
> >used. And now you need to give a good reason to forbid it.
> >Reducing the size of QtCore might be a good reason, but just saying
> >"it's for
> >your own good" is not.
>
> Agree with Olivier.
>
> Let's keep the level of support we had in Qt 4.x for throwing exceptions
> from slots:
>
> * It's undefined behaviour unless the place that emits the signal is
> prepared to catch the exception.
> * If a slot throws, no further slots connected to the signal will get
> called
> * throwing from any place that's connected to a signal defined in the Qt
> libraries leads to undefined behaviour
>
> The size reduction of QtCore is not a valid argument IMO. First of all
> we're talking about a number below 10%, and secondly this number could be
> reduced to almost 0 by making the build system for Qt Core only compile a
> few selected files with exception support enabled.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
