[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

On Friday 6 September 2024 10:55:47 CEST Ville Voutilainen wrote:
> > 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.

I meant the Qt code that the exception propagates through before reaching 
yours. I'm thinking of things like an accidental violation of a QList in one 
of the lists in QObjectPrivate::extraData, like runningTimers. Suppose the 
main() function puts the precondition checker in throw mode and that we do 
have a bug somewhere that triggers this violation deep inside servicing 
timers.

The exception will get thrown instead of the application aborting, but then 
it'll propagate through Qt code that has never been tested for exceptions. I 
argue that your best bet here is that it attempts to propagate through Win32 
DLLs or some Cocoa or Glib native APIs, which cause it to crash.

Because the alternative is that it reaches an exception handler somewhere and 
the user code may attempt to do something while the QObject and event 
dispatcher state is corrupt:

> > 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.

See above. In the scenario I outlined, you cannot trust anything that uses 
QObject any more.

And worse than crashing it is continuing to run with corrupted state. It may 
freeze or have weird, user-visible behaviours. Or it may corrupt user data, 
which then may be saved to disk, making it permanent and the data error not 
getting caught.

> > 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".

Sure, but "bugs happen". I am arguing that putting the contract checker into 
exception mode expands the blast radius of when those bugs do occur.

-- 
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/20240906/f6c5f965/attachment-0001.bin>