Re: [boost] [variant2] Andrzej's review -- design

Subject: Re: [boost] [variant2] Andrzej's review -- design
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-02 18:52:54

wt., 2 kwi 2019 o 19:23 Emil Dotchevski via Boost <boost_at_[hidden]>
napisał(a):

> On Tue, Apr 2, 2019 at 9:28 AM Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
> > It should be noted that variant2 DOES NOT PROVIDE A STRONG EXCEPTION
> SAFETY
> > GUARANTEE. The never-empty guarantee has a certain negative effect of
> > confusing people so that they are led to believe that they have strong
> > exception safety. But they don't. even expert programmers in this forum
> > expressed their surprise that changing from X to Y in variant<X, Y, Z>
> can
> > get them a variant storing Z. Sometimes it is even trickier: X may be a
> > container that currently stores 10 elements. You assign Y, and after the
> > exception you get an X that stores zero elements. Because of these
> > problems, the only reasonable thing to do is to follow the advice from
> Dave
> > Abraham's article: https://www.boost.org/community/exception_safety.html
> > To quote the relevant part, "If a component has many valid states, after
> an
> > exception we have no idea what state the component is in; only that the
> > state is valid. The options for recovery in this case are limited: either
> > destruction or resetting the component to some known state before further
> > use."
> >
> > If this principle is followed no-one will ever observe the
> > valueless_by_exception state. This also applies to variant2. If this
> > principle from Dave Abrahams is followed, no-one will ever benefit from
> the
> > never-empty guarantee (but people will still pay the costs of providing
> > it). You cannot do anything meaningful with variant that threw other than
> > destroy or reset it. (But it is probably best to destroy it.) If objects
> > are allowed to survive the stack unwinding, they should either offer a
> > strong exception safety guarantee, or you have to have some very detailed
> > knowledge of a given particular type how its state gets modified under
> > exceptions, but this is usually very difficult and best left to experts.
>
> The argument for a variant type that never ends up in a "valueless" state
> is not that it is wonderful to deal with objects that change state from X
> to Y, but that error recovery code is already difficult to write correctly,
> and while dealing with an object found in a state we didn't leave it in
> (basic exception safety guarantee) may be annoying, this is preferable than
> having to deal with objects that explode unless they're destroyed. It's not
> that programmers "want" to do something with the object other than
> destroying it, but 1) it is difficult to ensure that this can never ever
> happen and 2) the way it can be ensured is to sprinkle checks at random
> places (e.g. where variant asserts are triggered when during error recovery
> some code happens to touch an object but not destroy it), which is even
> worse.
>

Please, illustrate it with an example. Maybe you have some good scenario in
mind, but to me, the necessity of sprinkling checks at various places is an
indication of a bad approach to exception handling. If I just unwind the
stack and let all my objects die, there is no point where I would need any
checks.

Regards,
&rzej;