[Development] Disavowing the Lakos Rule for Q_ASSERT

[Ville Voutilainen]

On Mon, 26 Aug 2024 at 22:51, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Monday 26 August 2024 12:27:47 GMT-7 Giuseppe D'Angelo via Development
> wrote:
> > Il 26/08/24 19:56, Thiago Macieira ha scritto:
> >
> > > I'd like to request Qt code not obey that rule. In my opinion, it's a
> > > defect
>  in the contract implementation rather than on Qt code. The*pre*
> > > condition indicates something that must be true before the method is
> > > called and therefore the method's own noexcept specification does not
> > > apply*yet*.
> >
> > As far as I've understood, that's only part of the issue. The other part
> > of the issue is that code calling the function may break: if you turn
> > the failed precondition check into an exception, the exception handling
> > will need to bubble it up through code which may not have set up the
> > correct unwinding state -- because it rightfully assumed that no
> > exception would escape out of a noexcept function.
>
> How is that my problem? My code didn't throw. It was the user's action of
>  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.

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