[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240905/d8e1a678/attachment-0001.bin>