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

Subject: Re: [boost] [outcome] success-or-failure objects
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2018-01-23 23:39:28

On Tue, Jan 23, 2018 at 2:40 PM, Gavin Lambert via Boost <
boost_at_[hidden]> wrote:

> On 24/01/2018 11:13, Emil Dotchevski wrote:
>
>> There's a sizeable number of people who are very keen on doing so. Hence
>>> std::logic_error and family i.e. WG21 historically has agreed.
>>>
>>
>> It is unreasonable to think that a program that has just encountered a
>> logic error can recover gracefully from it any more it can do so from a
>> crash. Try to recover, and you might make things worse, possibly much
>> worse.
>>
>
> Not necessarily.  It depends on how well-partitioned things are and how
> far-reaching the side effects executed thus far affect other things.
>
> For an example, think of a web browser.  At some point it parses some
> malformed HTML and sets a property local to the page to null.  At some
> later point something accesses that property without checking for null
> first.  This is a logic error, but it's a completely benign and recoverable
> one (at least on platforms where memory around null is guaranteed to be
> invalid).  The browser can recover simply by aborting the load/render of
> that page and showing an error, without affecting any other pages or
> crashing the browser itself.
>

This fits my "any more it can do so from a crash" caveat, but the problem
is that while in a given program there might be a subset of logic errors
that can be classified as "benign", this requires knowing the exact nature
of the logic error; it is unsafe to make this assumption in the abstract
about all logic errors.

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.

> Other similar cases exist, where a data structure might be left in an
> undefined but still destructible state

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

> but it doesn't matter because the error recovery process will just destroy
> that structure anyway.

No, it will attempt to destroy it. The result cold be a nice error message,
but it could end up sending a nasty email to your boss instead.

Emil