[Development] Disavowing the Lakos Rule for Q_ASSERT

[Ville Voutilainen]

On Thu, 5 Sept 2024 at 12:24, Thiago Macieira <thiago.macieira at 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.