Re: [boost] [outcome] Exception safety guarantees

Subject: Re: [boost] [outcome] Exception safety guarantees
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-27 22:57:05

2017-05-28 0:45 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:

> Andrzej Krzemienski wrote:
>
>> But tell me this. Consider the example with class Man above:
>>
>> ```
>> struct Man { std::string fist_name, last_name; };
>> Man m1 = {"April", "Jones"};
>> Man m2 = {"Theresa", "May"};
>>
>> try {
>>   m2 = m1; // suppose it throws
>> }
>> catch(...)  {
>> }
>> ```
>>
>> Object m2 after recovering from stack unwinding may be in the state
>> {"April", "May"}, which is a "valid state". Would you call it a valid state?
>>
>
> It depends on the invariant of Man. Assuming no invariant, yes, it's
> valid. It doesn't crash if I access it.
>
> Same with outcome<T>: if I assign to it and it fails:
>>
>> o1 = o2; // assume basic guarantee
>>
>> provided I get transactional guarantee, I know what its value is. But if
>> I get "basic guarantee" as you describe it (valid but unspecfied state),
>> what good does it make that I can safely call has_value() if the object
>> contains a different value than o1 or o2 had initially?
>>
>
> What good it makes is that you can call has_value() on it without crashing.
>
> Without this guarantee, you could never safely call has_value() on a
> foreign object without checking valueless() first.
>

Hold on. I am talking about "valueless_by_exception" which cannot happen
for just any reason: only when you tried to mutate the object and it threw
an exception in the middle. I am not talking about a default constructed
state. I get the result from the function:

```
expected<T, E> o = fun();
// (*)
if (o.has_value()) ...
```

Upon the call to has_value() how is it possible that I am experiencing the
valueless_by_exception state? Either I was trying to assign a different
value in between (what I marked with (*)) and caught exception (in which
case I am doing something fishy), or function fun() is already returning a
valueless_by_exception, but why? because it inside again is assigning, and
try-catching the assignment, which again is fishy.

IOW, my claim is that if in your code you have concerns whetherr calling
has_value is safe in the face of valueless_by_exception, you are doing
something wrong (catching exceptions prematurely).

Rgards,
&rzej;