[Development] Disabling exception support in QtCore?

Alex Malyushytskyy alexmalvtk at gmail.com
Fri Oct 4 02:11:54 CEST 2013


Assuming exceptions are enabled  for signal/slots what is going to happen
with Qt::QueuedConnection?
As far as I understand at this point you can't catch exception in the
signal.
That means you will have to do it in the event loop. What is going to
happen next? Re-throw it and an uncaught exception again?

In this case I would prefer to make sure exception never leaves the slot.

Alex




On Thu, Oct 3, 2013 at 11:08 AM, Thiago Macieira
<thiago.macieira at intel.com>wrote:

> On quinta-feira, 3 de outubro de 2013 09:43:18, Marc Mutz wrote:
> > Qt is a general-purpose framework library. As a library, its *only*
> > purpose is to serve its users; as a framework, it mandates a certain
> > structure on programs using it. As a general-purpose library, it can
> > only assume very little about how users of the library use the library.
> >
> > If those users want to use exceptions, which is still a standard C++
> > feature, last I checked, Qt should go out its way to enable those users,
> > while at the same time giving users that _don't_ want exceptions a way
> > to switch them off.
>
> I am assuming you mean "users who want to use exceptions in their own
> code".
> That explicitly rules out using exceptions when interacting with Qt code.
> The
> only grey area is template code when used with a type from the user.
>
> Requiring a third-party library to support exceptions when they don't care
> is
> like asking a C library to support exceptions. Please point me to any
> discussion in Glib or APR or other generic C frameworks about them becoming
> exception-safe. Until then, we retain the right to make a decision whether
> exceptions can travel through our code, despite our choice of coding in
> C++.
>
> Our current decision is that they can't.
>
> > Forcing users of Qt to choose between not using
> > exceptions at all or writing try/catch blocks around the bodies of *all
> > of their slots*, because we removed the single spot where (buggily)
> > escaped exceptions could be centrally dealt with (main), is preposterous
> > at best and arrogant at worst.
>
> I disagree.
>
> First, we establish an API contract. We provide the boundaries for which
> the
> API works and how it works, inside those boundaries. If you violate the
> boundaries, undefined behaviour occurs.
>
> Let's say, for the sake of argument, that one of those boundaries is that
> you
> will not throw back to Qt code. And let's assume developers are following
> that
> guidance, to the best of their knowledge. If an exception escapes because
> of a
> bug in the user code, then it's a BUG. All discussion about how things
> should
> behave is already out of the window.
>
> In addition, I also dispute the usefulness of a global try/catch in main().
> What good is it to know that std::bad_cast or std::system_error happened,
> if
> you don't know where or what caused it? You're not going to display an
> error
> message to the user, there's nothing the user can do to correct the
> problem.
> You might say one would want to log the information for a developer to
> correct, but the catch block is too late already -- the stack has been
> unwound. The best thing you can actually have is a std::terminate() with a
> proper core dump.
>
> > IMO, we should support throwing exceptions through the event loop. We
> > don't (yet) have to guarantee that you can later re-enter the event loop
> > again, even though that's a valid mid-term goal.
>
> And IMO, we shouldn't have to. I maintain that event-driven programming is
> incompatible with exceptions.
>
> Unless you can answer this question: what exceptions can a mouse press
> generate?
>
> > Uhh, so there's the problem with Linux and The Single Distribution Build
> > To Rule Them All. So what? Build separate libraries. Were doing so for
> > debug support, too, and once upon a time, we did so for threads, until
> > we found we want to use them in Qt, too, and started requiring them.
> > Where are exceptions different?
>
> When Qt is part of the system API, there's only one Qt in the system.
>
> Choices are only available to application developers who bundle Qt with
> their
> applications. That's the feature system.
>
> When you have to interact with an existing system API, such as on
> Blackberry
> or Jolla or Ubuntu Phone devices, or on a KDE system, you don't have an
> option. Qt comes with the system, pre-built. You don't get to ask "my
> application doesn't use threads or QProcess or QFileSystemWatcher, so
> please
> remove QThread from Qt".
>
> > (As an aside: I just need to bring up Bjarne's quote from GoingNative
> > this year where he - convincingly, I might add - argues that in every
> > comparison of exception overhead, what is really being compared is code
> > that handles all errors in a defined way (assuming at least the Basic
> > Exception Guarantee is implemented in code) vs. code that handles no or
> > only selected errors. IIRC, he goes on to say that equivalent code
> > without exceptions would have both a higher runtime as well as a higher
> > maintenance cost than the exception-using code. Incidentally, that's the
> > guy that argued for -what?- 20 years that exceptions can be implemented
> > with zero runtime overhead in the non-throwing case until Windows AMD64
> > finally implemented it that way, so I would not dare to dismiss this
> > data point lightly).
>
> Thanks for the parentheses.
>
> But it's orthogonal to the discussion. Our numbers stand: 7% increase in
> code
> size because exceptions are enabled, on top of the non-exceptional error
> handling that already exists.
>
> Maybe the 7% is caused by our not having "noexcept" everywhere.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131003/a668630b/attachment.html>


More information about the Development mailing list