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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-27 03:57:10

> Question: if using the OUTCOME_TRY macro is equivalent to calling the
> function, checking for error and then returning an error if there is an
> error, how is this different from using exceptions? Semantically, exception
> handling does nothing more than check for errors and returning errors if
> there were errors, with much more readable syntax:

Semantically they are similar, and if the compiler implements EH using
SJLJ or any of the non-table approaches, they are also pretty much
identical in terms of implementation.

But on table-based EH, the cost of handling failure is many orders of
magnitude more expensive than handling success. OUTCOME_TRY emulates the
SJLJ balance of success/failure, you pay a constant fixed overhead
during successful codepaths in exchange for predictable overhead during
unsuccessful codepaths. So OUTCOME_TRY opts back into non-table EH
characteristics on table-based EH implementations.

Hence the "Decision Matrix" at
https://ned14.github.io/outcome/use-matrix/. There is no point in using
Outcome if failure almost never occurs. Use exceptions instead. But if
failure occurs in say 0.1% of the time, Outcome likely will win,
possibly even in 0.01% of the time depending. See
https://ned14.github.io/outcome/faq/#what-kind-of-performance-benefits-will-using-outcome-in-my-code-bring

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/