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?
---------------------------------------------
std::error_code&co tried to solve or at least alleviate the problem of
overhead of using exceptions (in terms of both source code verbosity and
binary code size&speed) with functions which need to report failures
that need not be 'exceptional' depending on the context of the call
(thereby requiring try-catch blocks that convert exceptions to 'result
codes'). Unfortunately, the way it was finally implemented,
std::error_code did not quite accomplish what it set out to do:
• in terms of runtime efficiency: 'manual'/explicit EH (try-catch
blocks) is no longer needed but the compiler still has to insert hidden
EH as it has to treat the functions in question as still possibly
throwing (in fact the implementation/codegen of functions which use
std::error_code for error reporting becomes even fatter because it has
to contain both return-on-error paths and handle exceptions)
• in terms of source code verbosity: again, try-catch blocks are gone
but separate error_code objects have to be declared and passed to the
desired function.
Enter boost::err: 'result objects' (as opposed to just result or error
codes) which can be examined and branched upon (like with traditional
result codes) or left unexamined to self-throw if they contain a failure
result (i.e. unlike traditional result codes, they cannot be
accidentally ignored). Thanks to latest C++ language features (such as
r-value member function overloads) incorrect usage (that could otherwise
for example lead to a result object destructor throwing during a
stack-unwind) can be disallowed/detected at compile time.
Discussions where the concept (or a similar one) was first concieved of
and/or so far discussed:
•
http://boost.2283326.n4.nabble.com/system-filesystem-v3-Question-about-error...
• http://cpptips.com/fallible
• https://github.com/ptal/std-expected-proposal
• https://github.com/ptal/expected
•
https://github.com/adityaramesh/ccbase/blob/master/include/ccbase/error/expe...
•
http://stackoverflow.com/questions/14923346/how-would-you-use-alexandrescus-...
•
https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:Strongl...
• http://2013.cppnow.org/session/non-allocating-stdfuturepromise
****************************************************************
For starter's, to reduce the length of the first post, I'll assume that
everyone as at least somewhat familiar with similar/related proposals
from Andrei Alexandrescu (std::expected) and Niall Douglas (std::monad)
to which I gave links above.
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