Re: [boost] expected/result/etc

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"...
>
Hi,

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].

Best,
Vicente

[1] Handling Disappointment in C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0157r0.html

[2] Survey of Error Handling
https://11080372623597421729.googlegroups.com/attach/a8bf61b2beb10bec/Survey%20of%20Error%20Handling.html?part=0.1&view=1&vt=ANaJVrGXbT5TGHEPTZWW_iduAUmJBNCyB6yvlV3L0LQk5eZ3dsCSBPSx0hql8fZ3MMCGjw-xBx8bIt6e4-4A0q_fE1U_7jREulA6RbE2Roh4sHOov8TUMtw