Re: [boost] [err] RFC

Le 17/11/2015 01:45, Domagoj Saric a écrit :

https://github.com/psiha/err README.md copy-paste:

--------------------------------------------- err - yet another take on C++ error handling.

We have throw and std::error_code, what more could one possibly want? ---------------------------------------------

What, primarily, makes (Boost.)Err different from other proposals is the ability to (using latest C++ features) detect/distinguish between temporaries and 'saved' return values by using two different class templates (result wrappers), fallible_result (for rvalues) and result_or_error (for lvalues) and thus minimise or often completely eliminate any extra verbosity: If we had a function foo() that produces bar_t objects but can fail with an err_t, up till now we had two options: * bar_t foo() throw( err_t ); * optional foo( err_t & );

Err enables the library writer to write a single API and a single implementation: err::fallible_result foo(); where fallible_result is the class template that wraps temporaries/rvalues returned from functions and its member functions are all declared with && (i.e. callable only on rvalues) so you get a compiler error if you save it to an auto value and try to do anything with it. The two exceptions are the implicit conversion operators to: - bar_t, which will either return bar_t or throw err_t and which is used for the 'EH code path' bar_t my_bar( foo() ); - err::result_or_error which is used for the 'oldsk00l nothrow error code path' err::result_or_error maybe_bar( foo ); if ( maybe_bar ) { print( *maybe_bar ); } else { log( maybe_bar.error() ); }

Also, if the fallible_result rvalue is left uninspected and contains an error its destructor will throw (which AFAICT should be safe considering it is an rvalue and no other exception can possibly be active at the same time) - this makes code that uses Err enabled libraries/APIs but relies on EH almost indistinguishable from 'classic EH' APIs (almost because the one difference that remains is with the immediate use of the return value: because of the wrapper class one can no longer write foo().do_something() but has to implicitly use the -> operator and write foo()->do_something() where the -> operator will check-and-throw if foo() did not succeed).

To wrap up, this approach gives the user the immediate and fine grained control over which error handling mechanism he/she wants to use while allowing the developer to write a single API and implementation - AFAICT it is a no brainer replacement for , it is less verbose and much more efficient ;-)

ps. the small library @ https://github.com/psiha/err is by no means a finished product, it contains no tests or documentation but 'it works' (i.e. it is used in the, also upcoming, https://github.com/psiha/mmap)...I'm bringing it to public view for scrutiny, discussion and guidance lest I steer in the wrong direction ;)

Hi, I like the idea of having a movable only class that is used as the result of a function and that ensure that the error is checked (TBoost.Expected has an ensure_read error class that terminates if the error is not read) and the conversion to a copyable that is used to pass this result as parameter to a function. However how do you prevent that the user forget to check for the error in the converted err::result_or_error? Wondering if expected and expected wouldn't be equivalent if expected is constructible from expected? Vicente