Re: [boost] expected/result/etc

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

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