Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-01-29 10:55:46

2018-01-27 21:49 GMT+01:00 Emil Dotchevski via Boost <boost_at_[hidden]>
:

> On Fri, Jan 26, 2018 at 7:57 PM, Niall Douglas via Boost <
> boost_at_[hidden]> wrote:
>
> > > Question: if using the OUTCOME_TRY macro is equivalent to calling the
> > > function, checking for error and then returning an error if there is an
> > > error, how is this different from using exceptions? Semantically,
> > exception
> > > handling does nothing more than check for errors and returning errors
> if
> > > there were errors, with much more readable syntax:
> >
> > Semantically they are similar, and if the compiler implements EH using
> > SJLJ or any of the non-table approaches, they are also pretty much
> > identical in terms of implementation.
> >
>
> I was only talking about semantics. Are you saying that, except for
> performance considerations, there is no reason to use
>
> OUTCOME_TRY(handle, open_file(path));
> OUTCOME_TRY(buffer, read_data(handle));
> OUTCOME_TRY(val, parse(buffer));
> return val;
>
> instead of
>
> return parse(read_data(open_file(path)));
>

It is my understanding that one of the situations that would prompt you to
use Outcome is when you want to make all failure execution paths explicit
and you want the compiler to help you with verifying that. In that case the
variant:

```
return parse(read_data(open_file(path)));
```

is inferior because failure execution paths are not explicit. On the other
hand, while you want failure execution paths to be explicit, you often
still want the code to be concise and not distract the reader too much from
following the positive execution paths. Operator TRY gives you a reasonable
compromise.

Also, it is not everywhere that you would use operator TRY. In more
complicated control flows you will prefer manual if-statements. Exceptions
and operator TRY are good for the cases where one operation always requires
the previous operation to succeed as a precondition. But sometimes the
dependency between operations is more complicated than this.

Regards,
&rzej;