[Development] Disavowing the Lakos Rule for Q_ASSERT

Ville Voutilainen ville.voutilainen at gmail.com
Thu Sep 5 10:41:51 CEST 2024


On Wed, 4 Sept 2024 at 14:35, Thiago Macieira <thiago.macieira at intel.com> wrote:
> > I also question the notion of "we don't do exceptions in Qt" popping up
> > between the lines in this thread. We _do_ support them in QtCore and
> > QtTest, and it's Core you're proposing to plaster with noexcept.
>
> We partially support them in the container classes, indeed. But we don't test
> them so anyone trying to use them right now is asking for trouble. To enable
> throwing contract violations requires first fixing all of that.

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.


More information about the Development mailing list