Boost logo

Boost :

Subject: Re: [boost] [outcome] success-or-failure objects
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-01-24 01:36:26

On 24/01/2018 12:39, Emil Dotchevski wrote:
> The motivation behind "doing something" in response a logic error is,
> obviously, to soften the impact of the bug on the user. The problem is that
> without knowing what went wrong, "doing something" might make the impact
> much worse. If you step on a mine, it's probably not a good idea to keep on
> walking.

In the general case I completely agree. I'm just pointing out that the
general case is not all cases.

Granted, once the kind of errors shift from null references to things
like use-after-free or double-free (or unchecked out-of-bounds), then
all bets are off and chaos can and will ensue with little hope of
recovery (unless the app has been careful to correctly use arena
allocators). These types of errors are less common with modern smart
pointers, though.

But we're not even really talking about those things, we're talking
about parameter validation and state preconditions.

Ideally, public APIs should not trust their callers to pass sane
arguments or refrain from calling a method in an inappropriate state,
and should by default verify this and throw (with an option to disable
it in release builds for performance, or keep doing it). Private
methods can do whatever they like, assuming they have sufficient test
coverage including things like ASan and UBSan.

This is why things like debug iterators exist. (And should be used more
often for custom iterators.)

> This is an oxymoron. If the state is undefined, you don't know if it is
> destructible.

Tell that to moved-from objects.

(I'm using "undefined" in the English "it could be in one of many
intermediate states" sense, not the Standard "dogs and cats living
together" sense. Mutexes might be broken, the data might be silly, and
the class invariant might have been violated, but it is probably still

Boost list run by bdawes at, gregod at, cpdaniel at, john at