
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-... Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/