Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-23 10:35:43

2017-05-23 8:50 GMT+02:00 Andrzej Krzemienski <akrzemi1_at_[hidden]>:

>
>
> 2017-05-23 1:56 GMT+02:00 Jared Wyles via Boost <boost_at_[hidden]>:
>
>> Hello,
>>
>> One of the questions that is inevitably asked when a proposal to switch to
>> using something like outcome is that of exceptions. Why outcome over
>> exceptions etc which you briefly touch on in your ACUU talk. With that in
>> mind, when attempting to sell this library having the motivating example
>> on
>> the boost.outcome docs using exceptions really makes starting the
>> discussion
>> harder. I understand one can never escape exceptions, but it shouldn't be
>> used as the first example a new user sees. I would like to see this
>> example
>> updated to show how to handle errors with out the need for exception
>> handling around accessing *value*. Personally, I see something similar to
>> https://ned14.github.io/boost.outcome/md_doc_md_03-tutorial_
>> b.html#expected_payload
>> as a much better example to help sell outcome and therefore better suited
>> as
>> the motivating example for the front page of the docs.
>>
>
> This means, the initial example should use `boost::outcome::result`
> (instead of `boost::outcome::outcome`). And then function that inspects the
> result could read:
>
> ```
> void test()
> {
> if (auto r = fun)
>   use_int_value(r.value());
> else
>   inspect_error_code(r.error());
> }
> ```
>

The initial example could look like this:
https://github.com/akrzemi1/__sandbox__/blob/master/outcome_intro.md

Regards,
&rzej;