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.macie...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development