[Development] Disabling exception support in QtCore?

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131003/38eec952/attachment.sig>