On Thu, 5 Sept 2024 at 12:24, Thiago Macieira <thiago.macie...@intel.com> wrote: > > 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.
I would be rather surprised if you had tested that code before, because it's my application code where that exception propagates, not Qt framework code. > It may also be caught somewhere and execution incorrectly resumed, causing > incorrect-state execution to continue. There's nothing incorrect about that; the exception will be caught and handled, and application execution will resume. > 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. I have that "correction code". > don't test and ascertain that our code is safe with exceptions, we should not > enable it. The exception unwind doesn't hit any of 'our code'. > 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. I quite fail to see why. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
