[Development] Disabling exception support in QtCore?
bm_witness at yahoo.com
Thu Oct 10 17:22:44 CEST 2013
On Thursday, October 10, 2013 9:26 AM, Olivier Goffart <olivier at woboq.com> wrote:
> On Thursday 10 October 2013 15:14:02 André Somers wrote:
> > Op 10-10-2013 14:53, Olivier Goffart schreef:
> > > On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote:
> > >> On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote:
> > >>>> I dislike allowing this via the signal-slot mechanism because I see
> > >>>> throwing from a slot as incompatible with the connection semantics.
> > >>>>
> > >>>> 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.
> > >>
> > >> That's not at all true. If it were, we wouldn't have signals or slots in
> > >> our public API. If people were supposed to write the signals and the
> > >> slots they connect, all our signals and slots would be private.
> > >
> > > I did not said that the signal and the slot were always written by the
> > > same
> > > person. And I explicitly said for an application, and you are talking
> > > about libraries.
> > Even for applications this statement is nonsense. For all but trivial
> > applications that during their lifetime only get worked on by a single
> > developer, the likelyhood of the same person always writing the slots
> > for every signal goes to 0 rapidly with the age and number of developers
> > on a project.
> That's not what I said.
It may not have been what you said, but it is what would occur.
> And regardless, I don't think it has any relevance for the problem in
> Within a code base that uses exception, developers should know which part of
> the code is exception safe and which part of the code can throw exception.
> And they know they should not call a function that can throw an exception from
> code that is not exception safe. (Hence they don't connect a signal from code
> that is not exception safe to a slot that throw an exception)
So now you have to a wrapper slot to wrap exceptions for any object from a library
that you may interact with, or potentially any other code in your own project.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development