Boost logo

Boost :

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
>> 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:


Boost list run by bdawes at, gregod at, cpdaniel at, john at