On Thursday 5 September 2024 10:41:51 CEST Ville Voutilainen wrote: > Well, not necessarily. Consider QVector::operator[]. You can make that > non-noexcept, slap a precondition > on it, and use a throwing violation handler. > > Everything works fine. There's no need to make the QVector code > exception safe, because it is not entered > on a precondition violation. The precondition violation and the > subsequent throw happen before we ever > get into whatever code is in QVector::operator[], exception-safe or not. > > Sure, there's Qt-internal code using QVector, and that code wouldn't > work with exceptions thrown from operator[]. > But *that* seems like a moot point, because in the presence of such > precondition violations, meaning out-of-bounds > accesses, the code using QVector::operator[] is hardly going to work > anyway, exceptions or not, because it's going > to be far away in the land of Undefined Behavior.
True, but there's a large difference between a contained failure and making the problem worse. The options in such a precondition violation are: a) not check and cause UB - that's what happens today in our regular, release builds b) check with an assertion - possible today by deploying a release-with- assertions build c) check with an exception - not possible today I'm arguing that (c) makes it *worse* because now the exception propagates out, causing all sorts of code to be run that we've never, ever tested before. It may also be caught somewhere and execution incorrectly resumed, causing incorrect-state execution to continue. My argument is "first, do no harm" (or "don't make it worse"). Exceptions should only be used if there's a proper correction code for it. And if we don't test and ascertain that our code is safe with exceptions, we should not enable it. If it is possible for user code to compile with it and ours with out, great, let's investigate that. If the implementation decides to make it a runtime choice (as Marc says, decided by the owner of main()), we'll need to be very clear we do not support it and do not recommend it. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
