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-31 11:53:53

2018-01-30 22:07 GMT+01:00 Emil Dotchevski via Boost <boost_at_[hidden]>
:

> This is my review of Outcome v2.
>
> Further, I disagree with the motivation to avoid using exceptions to begin
> with. The supplied decision matrix, I think, does not reflect reality. In
> my experience, the decision matrix to use C++ exceptions vs. something else
> is much simpler: "Do you hate exceptions?" No => use exceptions, Yes => use
> something else, because exceptions suck.
>
> Yes, exception handling has overhead. No, you can't afford this overhead in
> every last corner of a complex program, but yes, you can afford it in
> general. I have had many discussions on this and other "but but but
> Overhead" topics, and I have never been given actual evidence that any
> given program that does not use exceptions to report errors could not be
> written using exceptions to report errors, without sacrificing performance.
> And this is trivially true: if exception handling causes problems in some
> subsystem, the solution is to hide that subsystem behind a C-style API and
> compile only that subsystem with exception handling disabled.
>
> So, the design of "an error handling library that does not use C++
> exceptions" has to target the tricky bits where exceptions would be
> annoying or can't be used, not the general case where they can.
>
> Finally, I'll point out that a lot of the positive feedback comes from
> people who think that it is a good idea to replicate the Rust error
> reporting mechanism in C++. This seems to be an axiomatic belief, since
> I've never seen anyone attempt to substantiate it. This is important, as it
> is typical for programmers coming from other languages to be shocked by
> various C++ language features, and this should not be confused with
> problems in the C++ language specification.
>

I feel I need to respond to this. My remarks are only to this single
argument about the superiority of exceptions -- not to the review and other
arguments.

Because you say this in the context of Boost.Outcome review it sounds a bit
as if you were saying "I am against Boost.Outcome, because exceptions
should be preferred to any other failure handling mechanisms". I do not
know if you are really saying this, but this is the impression I get.
Please correct me if I am wrong.

While the introduction to docs mentions "The high relative cost of throwing
and catching a C++ exception", it also lists other use cases that are not
related to performance. Are you also questioning other motivations for
using this library?

You yourself admit that there are small isolated places in the code where
it makes sense to use an alternative to exceptions for failure reporting.
And would you not accept the library that may be the best alternative to
exceptions in those isolated cases?

Exceptions play well in the most common situation where failure to execute
some instruction `x` should prevent the execution of the subsequent
instruction. If this is not the case, exceptions just add mess compared to
manual control flows. This is not limited to C callbacks. I had similar
problems inside a task framework.

Boost.Outcome is not to "replace exception handling in your programs": it
is used to cover those isolated places where exception handling proves
inferior to manual control flows. That is, there might be people who will
chose to use it everywhere, but it is their choice. They might have used
`boost::variant` as well. Boost.Outcome does not come with recommendation,
"use it instead of exceptions everywhere".

And you are actually saying the same thing. Except that somewhere you
appear to arrive at the conclusion that this library should be rejected
because of being alternative to exceptions. And I cannot understand this.

And I note that I am not familiar with Rust. My motivation for using this
library is that I have observed places in my programs where exceptions just
make the flow more complicated, and I needed to use something else so that
the code reflects my intentions more directly, and Boost.Outcome addresses
those issues.

Regards,
&rzej;