2018-01-27 21:49 GMT+01:00 Emil Dotchevski via Boost
On Fri, Jan 26, 2018 at 7:57 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
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.
I was only talking about semantics. Are you saying that, except for performance considerations, there is no reason to use
OUTCOME_TRY(handle, open_file(path)); OUTCOME_TRY(buffer, read_data(handle)); OUTCOME_TRY(val, parse(buffer)); return val;
instead of
return parse(read_data(open_file(path)));
It is my understanding that one of the situations that would prompt you to use Outcome is when you want to make all failure execution paths explicit and you want the compiler to help you with verifying that. In that case the variant: ``` return parse(read_data(open_file(path))); ``` is inferior because failure execution paths are not explicit. On the other hand, while you want failure execution paths to be explicit, you often still want the code to be concise and not distract the reader too much from following the positive execution paths. Operator TRY gives you a reasonable compromise. Also, it is not everywhere that you would use operator TRY. In more complicated control flows you will prefer manual if-statements. Exceptions and operator TRY are good for the cases where one operation always requires the previous operation to succeed as a precondition. But sometimes the dependency between operations is more complicated than this. Regards, &rzej;