[Development] Disavowing the Lakos Rule for Q_ASSERT

[Fabian Kosmale]

Hi,

I'm somewhat sympathetic to Thiago's proposal, but with different reasoning. The Lakos rule is indeed motivated by contracts, and by the fact that the standard is extremely reluctant to do breaking changes.
Now, contracts will be in no earlier than C++23 even in the best case (and personally I believe 26 is more realistic, but let's see). Given that we're currently very reluctant to use even C++20 features, and given that we have a certain amount of leeway for behaviour changes between Qt major versions, I'm not quite sold on the fact that we have to consider that rule for our API design, especially in Qt which gives  generally weaker guarantees for exception handling than the standard.

 As far as rules go: A function can be noexcept, if it doesn't ever throw exceptions - sounds pithy, but of course that means among other things no allocations, and error handling has to use a non-exception mechanism (be that std::expected  or just  fatal termination).

If we instead consciously decide to follow the Lakos rule, I'd also be inclined to discuss how we should then handle exceptions arising in many more places (which would have a "fun" impact on at least. QML).

Fabian

________________________________________
Von: Development <development-bounces at qt-project.org> im Auftrag von Marc Mutz via Development <development at qt-project.org>
Gesendet: Montag, 26. August 2024 21:55
An: development at qt-project.org
Betreff: Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

On 26.08.24 19:56, Thiago Macieira wrote:
> The Lakos Rule says that methods that only methods with wide contracts should
> be noexcept. That is, if your method has a precondition, it should not be
> noexcept.
>
> This is apparently predicated on the fact that the preconditions will be
> implementable as C++ contracts some time in the future and that some compilers
> or compilation modes may turn contract verifications into runtime checks.
> Moreover, said checks can be implemented by throwing an exception indicating a
> contract violation. Alternatively, an application could replace the Qt
> assertion handler with one that throws (which is currently not possible
> because qt_assert is noexcept, therefore this replacement is not supported).
>
> 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*.

I don't see a proposal for an alternative rule in the above. Please
provide a) a new rule and b) rationale for it. Bonus points for being
implementable in a static checker like Clazy or Axivion.

Background: The Lakos Rule has been the status quo for the last decade
in C++ and Qt. It is easy to explain and should be pretty
straight-forward to check. I don't think we as the Qt project are
qualified to come up with a rule that differs from what std is doing, so
I strongly suggest not to try. Alternatively, we need _very_ good
reasons to diverge from what std is doing, not just one developer's hunch.

Allowing Q_ASSERT to throw into QtTest would be a big step towards
better testing of failure conditions, something that surely becomes more
important over time as pressure from legislators on unsafe-memory
language libraries increases. Any function in-between that's incorrectly
marked as noexcept prevents that check from working, until it can be
fixed in the next major release (removing noexcept is BiC). So not only
do we have _no_ incentive to diverge from std, we also have a rather
large incentive to keep doing what std is doing.

Thanks,
Marc

--
Marc Mutz <marc.mutz at qt.io> (he/his)
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development