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

On Tue, Apr 23, 2013 at 3:28 PM, Pierre T. wrote:

Le 23/04/2013 18:55, Gottlob Frege a écrit :

We can throw anything we want. I'm not sure it is a good idea, but you

...

can throw anything. It doesn't need to derive from std::expection, for example. You can throw an int. etc.

Of course, but I guess it's a bad practice ?

I'd agree with that.

...

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).

We could use something similar in expected. But we must keep in mind that expected has a value and an error, is it clear that *expect return the value and not the error ?

Yes. It is called "expected" after all. You expect the value, not the error. And if there is an expect.is_valid() I expect it to be referring to whether the value is valid, not the error. Etc. It is not called "std::pair", it is expected. IMO, at least.

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.)

Tony

I guess that the idea of error_wrapper_exception<Error> is interesting. Mainly because it enables us to have an unique variant of expected. However, if Error is an exception, it shouldn't be encapsulated into a error_wrapper_exception.

I don't like special cases, but I can imagine checking at compile time whether Error derives from std::exception or not. But that means anyone using their own (non-std) exception hierarchy, expected doesn't give what they... expected. One option would be expected With the 3rd arg deciding whether to wrap or not - or wrap-if-derived-from-exception. Which could default any which way. But I lean towards thinking that Error is rarely or never an exception - if it was, why use expected<> at all? Just throw the exception. I think of expected<> as being used in places where you don't want to use exceptions. ie if you have expected someFunction(); where someFunction() could *return* an exception, why not just int someFunction(); // throws SomeException So I think I'd prefer it always to wrap. ie assume that the Error is NOT an exception, and not meant to be thrown. The only time it is thrown is when someone (mistakenly? ie coder error) accesses the value via expect.value() and it throws bad_expected_access<Error>. Or "un_expected_access" :-)

What others think about this behavior and interface ?

Thanks for any comments. Pierre Talbot.

I'd definitely like to hear more from others. Maybe I'm not imagining some of the ways this is expected to be used. Tony (all puns are purely intentional.)