Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2016-02-04 17:02:55

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

[1]
https://github.com/psiha/err/blob/master/include/boost/err/errno.hpp
https://github.com/psiha/err/blob/master/include/boost/err/win32.hpp

-- 
"What Huxley teaches is that in the age of advanced technology,
spiritual devastation is more likely to come from an enemy with a
smiling face than from one whose countenance exudes suspicion and hate."
Neil Postman