Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-02-06 15:48:26

On Sat, Feb 6, 2016 at 3:53 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> 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"...
>>
>> <snip>
> [1] Handling Disappointment in C++
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0157r0.html
>

Generally I take issue with claims that exception handling overhead can
cause performance problems. The linked paper mentions one of the problems
being variance in execution time between the error-no error execution
paths, which can't be addressed anyway since detecting an error early on in
an attempted operation may skip significant amount of code. Another stated
concern is that exception handling introduces overhead throughout the
program even when exceptions are not being propagated, however such
overhead (if any) is limited to function call and exit points. In
performance-critical contexts function calls are too expensive with or
without the added overhead of exception handling, and the solution is to
inline the function. In that case all function call overhead disappears,
including the exception handling overhead.

Emil