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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk