On Mon, Jan 29, 2018 at 2:55 AM, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
2018-01-27 21:49 GMT+01:00 Emil Dotchevski via Boost < boost@lists.boost.org> :
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