Re: [boost] expected/result/etc

On Sat, Feb 6, 2016 at 3:53 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> 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 wrote:

...

Hopefully these efforts will bring us to a solution that will do away the, IMO, false dichotomy between "errors" and "exceptions" ( 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