Boost logo

Boost :

Subject: Re: [boost] expected/result/etc
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-02-06 06:53:39

Le 04/02/2016 23:02, Domagoj Saric a écrit :
> On 29.1.2016. 1:57, Emil Dotchevski wrote:
>> On Thu, Jan 28, 2016 at 3:44 PM, Domagoj Saric <dsaritz_at_[hidden]>
>> wrote:
>>> Hopefully these efforts will bring us to a solution that will do
>>> away the, IMO, false dichotomy between "errors" and "exceptions"
>>> (<system_error> vs <exception>) - rather we will start thinking
>>> only about "errors"/error objects which can be transfered in two
>>> different ways - like a ball in a rugby game - it can be passed
>>> 'on foot' hand to hand or it can be thrown over intermediate
>>> players to its final destination (only with errors its in reverse -
>>> they are mostly passed/returned or thrown 'backwards':). IOW things
>>> like error_info will be applicable to 'the' standardized error
>>> type(s) that functions also return, not just throw.
>> You could theoretically pass exceptions function-to-function by
>> exception_ptr but that seems backwards, no pun intended. :)
> And we could theoretically and practically ;) return actual error
> objects (even those considered 'exceptions', e.g. std::runtime_error)
> w/o necessarily stuffing them into some type erasing mechanism like
> exception_ptr (i.e. you pass the ball as a ball until you need to
> interact with someone who only understands abstract UFOs;)
>> Anyway, my point is that there are two ways one can go about solving
>> the problem of transporting error codes. One is what seems to be the
>> path you're taking, where you design a common API that can fit all
>> error codes on all platforms. On the other hand, the Boost Exception
>> approach sidesteps this difficult problem.
> That's a separate issue. The "expected/result/etc" debate&proposals
> are first and foremost about the ('all new and improved') mechanism
> for passing errors around. The problem of how to abstract semantically
> 'similar' but syntactically 'not the same' error reporting mechanisms
> across platforms (such as your errno vs win32 last error code example)
> is orthogonal to this. However I do think that that problem should
> also be solved by the same library as the first one, i.e. that an
> err-like library would offer a std::result-like 'synthesis' of the
> 'error codes' vs 'exceptions' dialectic _and_ offer wrappers,
> abstractions and utilities to work with platform errors (e.g.
> NTSTATUS, HRESULT, win32 last error, errno[1], OSX OSStatus, ObjC
> exceptions, JNI etc.) and on top of that generalized
> Boost.Exception-like functionality - IOW a complete "error library"...

in case this could help. There were two reports on this subject.
"Handling Disappointment in C++" by L. Crowl [1] and the other in the
draft state "Survey of Error Handling" by N. Bolas [2].


[1] Handling Disappointment in C++

[2] Survey of Error Handling

Boost list run by bdawes at, gregod at, cpdaniel at, john at