Re: [boost] [gsoc-2013] Boost.Expected

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-23 18:24:01

Le 23/04/13 18:55, Gottlob Frege a écrit :
> On Tue, Apr 23, 2013 at 10:18 AM, Krzysztof Czainski <1czajnik_at_[hidden]>wrote:
>
>> 2013/4/23 Pierre T. <ptalbot_at_[hidden]>
>>
>> It's what I called
>>> expected_base<T, Error> in my previous mails, the get() on expected_base
>>> doesn't throw and if expected_base doesn't contain a value, then
>> undefined
I would expect an exception.
>>> behavior occurs.
>>>
>> Hmm, couldn't the original error be thrown anyway (if the wrapping type had
>> a virtual function that would throw the error)?
>>
>>
>>
> I think we'd like to avoid virtual functions.  I'm not even sure the base
> class is needed.  I think we only want one expected<>, not 2 or 3 variants.
> (Although maybe I don't understand what all the variants are, I haven't
> looked at it thoroughly.)
>
>
> What we did for optional<> is allow you to access the value in 2 ways:
>
> optional<int> oi;
>
> int x = oi.value(); // throws bad_optional_access
> int y = *oi; // undefined behaviour
>
> Similar to vector [n] vs at(n).
>
> I think expected<> should work the same way.
>
> The only question, to me, is what it throws.  Either it throws the Error,
> or it throws bad_expected_access.  Or it throws bad_expected_access<Error>
> which derives from bad_expected_access_base, or something like that.  (ie a
> well defined exception, but I can still get my custom Error value back from
> it if I want.)
>
IMO, expected::value()/get() must throw the container Exception (if any).
expected_or_error::value()/get() should throw bad_expected_access which 
would contain the error condition.  bad_expected_access could share the 
design of future_error.

Best,
Vicente