Re: [boost] [outcome] success-or-failure objects

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