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: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2018-01-29 18:56:30

On Mon, Jan 29, 2018 at 2:55 AM, Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

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

They are about as implicit as when using OUTCOME_TRY, because it too
removes the ifs from plain view. But that's a good thing, removing the ifs
is very desirable because leaving them in makes the code longer, more
difficult to read, more prone to errors. "Say, what happens if there is an
error?" "We just return the error, sir!" "Oh okay, carry on then!"

Perhaps you mean that you could easily forget that e.g. open_file may
throw. That's true, it takes a while to switch into the mindset that
anything may throw.

> Also, it is not everywhere that you would use operator TRY. In more
> complicated control flows you will prefer manual if-statements.

Yes! This is one of the practical (as opposed to simply a matter of
stylistic preference) use cases in my mind: when it would be annoying to
deal with an exception from a particular function. Formally, this is the
case when you need to be able to detect a failure, but there is no useful
postcondition to be enforced.

Another use case is when we are only storing, but not consuming the result
immediately so we need any exception throwing to be postponed until that
happens. In some APIs this can be very common.

Emil