[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

On Monday 26 August 2024 15:35:11 GMT-7 Ville Voutilainen wrote:
> >  a) turning precondition checks into runtime validations
> >  b) using exceptions for the runtime validation
> >  c) violating the precondition that caused the problem.
> 
> Right. Preconditions are as-if in the function body. Both for
> definition-side checks and for caller-client side checks.
> Otherwise a noexcept isn't a noexcept, and nobody wants that.

So an implementation could implement the verification of preconditions in the 
callee, which may need to throw exceptions to signify a violation, instead of 
duplicating it everywhere where the call is taken place. That makes sense... 
but I disagree. I don't want that.

It should instead emit an extra helper function that gets merged by all 
callers if they desire. That way, the callee can assume all preconditions have 
been verified and need not spend cycles. And callers don't need to check 
conditions that the compiler can prove are already met.

Maybe implementations will allow either or both verification modes.

> > In particular, I don't see why (b) should be used at all. A precondition
> > violation implies that the state was unexpected at that point. How is an
> > exception going to help recovering? That sounds like an exception that
> > would bubble up all the way back to main() and at best perform an
> > emergency save of state. But all of that is implementable with a
> > termination handler too.
>
> It doesn't mean that an exception will bubble up all the way to
> main(). A caller can catch it.
> See https://open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3318r0.html
> for some additional
> rumination. The state is unexpected, but recoverable - and that state
> doesn't mean that the program
> as a whole is in a completely undefined state, especially because the
> precondition check threw before
> such a state would've been entered. And it's not runtime _validation_.
> It's runtime recovery from logic
> errors. Java does this too.

This is one of the cases in your paper:

  "But you can't do that, a contract violation means that the program is in a 
  catastrophic and unrecoverable state"
  No, that's not at all what it means.

Yes, some preconditions can be coded such that the state is recoverable, as 
you're saying.

I am saying that a) that's not likely to be the case for the majority of 
preconditions, and more importantly b) it's not the case for the cases we are 
discussing right now.

I also urge you to expand on the case of std::vector::operator[]. Are you 
proposing that it a) become non-noexcept, b) have its UB not defined by the 
boundary of the precondition, or c) have a precondition that cannot be turned 
into an exception?

-- 
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/20240826/b1218b0c/attachment-0001.bin>