Subject: Re: [boost] Outcome v2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-11 22:16:45
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost <
> > Outcome does not solve the most important problem that needs solving by
> > error handling library.
> Does Expected?
Nope, but the original outcome<T> was closer. I thought, perhaps it is
possible to make it able to transport arbitrary error types, and not by
exception_ptr. My attempt at solving that problem lead me to TLS but maybe
there are other ways.
On the other hand, I don't see a problem with TLS, it seems the perfect
solution. And I don't necessarily mean this from performance point of view,
it's really a philosophical disagreement. The error object is a
communication channel between the error-detecting code and the
error-handling code; everyone else should keep quiet except maybe to add
relevant contextual data.
If you would accept this analogy, if I send you a package, it seems wrong
for the postal service to open it up and replace the contents with
something they think is better, but I'm fine with them slapping a label or
two on the outside of the box. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk