2018-01-30 22:07 GMT+01:00 Emil Dotchevski via Boost
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;