<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt">(sorry for jumping in the middle of the discussion)<br><br>>Quoting style guides that apply for applications can by definition not <br><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div class="y_msg_container">>contain reasoning for library writers. Apps live in their own little <br>>dream world and can play with the compiler flags anyway they wish. They <br>>only target one App, after all, and if they switch off exceptions or <br>>RTTI, no user user will care. Yes, LLVM also provides libraries. But <br>>they're narrowly-focused and, what's more important, they're toolkits, <br>>not frameworks. Meaning they don't force a particular structure on your <br>>program. Yes, there are probably
 checkers that use the LLVM libraries as <br>>a framework, but now we're really leaving the realm of general-purpose <br>>libraries and are comparing apples and oranges.<br>><br>>My pov on this whole discussion is this:<br>><br>>Qt is a general-purpose framework library. As a library, its *only* <br>>purpose is to serve its users; as a framework, it mandates a certain <br>>structure on programs using it. As a general-purpose library, it can <br>>only assume very little about how users of the library use the library.<br>><br>>If those users want to use exceptions, which is still a standard C++ <br>>feature, last I checked, Qt should go out its way to enable those users, <br>>while at the same time giving users that _don't_ want exceptions a way <br>>to switch them off. Forcing users of Qt to choose between not using <br>>exceptions at all or writing try/catch blocks around the bodies of *all <br>>of their
 slots*, because we removed the single spot where (buggily) <br>>escaped exceptions could be centrally dealt with (main), is preposterous <br>>at best and arrogant at worst.<br>><br><br>I'm not so sure if I follow your logic here, but Qt does not necessarily need to just blindly<br>provide everything the users might want. In this case I think that the benefits Qt will get<br>out of having two separate code paths for supporting and not supporting exceptions are not<br>enough to justify having those two code paths in the first place (and I think a large part of the audience<br>leans that way too).<br><br>>IMO, we should support throwing exceptions through the event loop. We <br>>don't (yet) have to guarantee that you can later re-enter the event loop <br>>again, even though that's a valid mid-term goal.<br>><br><br>Throwing exceptions without having a way to safely reenter the event loop is not very desirable.<br>It is the equivalent
 of being able to change the wheels in your car while driving it but not being able<br>to steer the car while doing it. In my book that is a big no-no.<br><br>If exception support is deemed necessary then that should be solved before the discussion continues.<br><br>>At the same time, there should be an easy way to build Qt with exception <br>>support disabled, for those apps that don't want to handle their errors.<br>><br>>Uhh, so there's the problem with Linux and The Single Distribution Build <br>>To Rule Them All. So what? Build separate libraries. Were doing so for <br>>debug support, too, and once upon a time, we did so for threads, until <br>>we found we want to use them in Qt, too, and started requiring them. <br>>Where are exceptions different?<br>><br><br>If you look at things under that light, they are not that different. But there is the underlying difference<br>that exceptions will produce out of order code paths
 that might produce subtle problems that might take<br>years to discover and fix. Debug symbols are easy, you either have them or not. Threads are even easier, you can build<br>a library with thread support and the same code will work without modifications if you remove thread support (well, mostly).<br>Exceptions on the other hand will require us to be able to assure that we can contain them safely _OR_ that we tell users<br>that they need to wait for unexpected exceptions.<br><br>The problem with exceptions is that there is no middle ground, as with for instance libc signals. You either start throwing them<br>and catching them or you don't. This proposal is just to make the latter the default case, which makes sense in my view.<br><br></div> </div> </div>  </div></body></html>