Does anyone actually have a measurable example of real code in which the
unexceptional path induces any more execution overhead than an
optional/variant/outcome return type?
Because when I look at the code generated by gcc et all, I am convinced
that you're solving a non-existant problem when seeking to replace
exceptions.
By all means have a partial return type such as outcome if a failure is to
result in a useful execution path.
But exceptions do not actually add overhead when used to signal actual
exceptions.
At least in the millions of lines of code I have written and read.
R
On 13 Jun 2017 19:01, "Peter Dimov via Boost"
Emil Dotchevski wrote:
If error codes are treated as "the error", then the error domain is limited to a single function. Consider these two functions:
int f1(....); //returns 0 on success, 1-f1_error1, 2-f1_error2 int f2(....); //returns 0 on success, 1-f2_error1, 2-f2_error2
If f2 calls f1, if the error is communicated by an error code, f2 _must_ translate the error condition from the domain of f1 errors, to the domain of f2 errors. And this must be done at every level, which introduces many points in the code where subtle errors may occur, and that is in error handling code which is very difficult to test and debug.
That's exactly the problem std::error_code solves, as it's a (code, domain) pair, so there's no need to translate.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost