[Development] Disabling exception support in QtCore?

[Carlos Duclos]

(sorry for jumping in the middle of the discussion)

>Quoting style guides that apply for applications can by definition not 

>contain reasoning for library writers. Apps live in their own little 
>dream world and can play with the compiler flags anyway they wish. They 
>only target one App, after all, and if they switch off exceptions or 
>RTTI, no user user will care. Yes, LLVM also provides libraries. But 
>they're narrowly-focused and, what's more important, they're toolkits, 
>not frameworks. Meaning they don't force a particular structure on your 
>program. Yes, there are probably checkers that use the LLVM libraries as 
>a framework, but now we're really leaving the realm of general-purpose 
>libraries and are comparing apples and oranges.
>
>My pov on this whole discussion is this:
>
>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. 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'm not so sure if I follow your logic here, but Qt does not necessarily need to just blindly
provide everything the users might want. In this case I think that the benefits Qt will get
out of having two separate code paths for supporting and not supporting exceptions are not
enough to justify having those two code paths in the first place (and I think a large part of the audience
leans that way too).

>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.
>

Throwing exceptions without having a way to safely reenter the event loop is not very desirable.
It is the equivalent of being able to change the wheels in your car while driving it but not being able
to steer the car while doing it. In my book that is a big no-no.

If exception support is deemed necessary then that should be solved before the discussion continues.

>At the same time, there should be an easy way to build Qt with exception 
>support disabled, for those apps that don't want to handle their errors.
>
>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?
>

If you look at things under that light, they are not that different. But there is the underlying difference
that exceptions will produce out of order code paths that might produce subtle problems that might take
years to discover and fix. Debug symbols are easy, you either have them or not. Threads are even easier, you can build
a library with thread support and the same code will work without modifications if you remove thread support (well, mostly).
Exceptions on the other hand will require us to be able to assure that we can contain them safely _OR_ that we tell users
that they need to wait for unexpected exceptions.

The problem with exceptions is that there is no middle ground, as with for instance libc signals. You either start throwing them
and catching them or you don't. This proposal is just to make the latter the default case, which makes sense in my view.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131003/972f4ae8/attachment.html>