Le 09/02/2016 10:16, Niall Douglas a écrit :
On 8 Feb 2016 at 23:27, Emil Dotchevski wrote:
But of course the two approaches use completely different strategies. In one case the programmer has to write if( error ) return error, like a neanderthal. In the other, he has to write exception-safe code but the upside is less error handling bugs, which is important as error handling code is notoriously difficult to test. In practice if you're returning an important outcome from a function then you'll always be using it, so you don't notice the fact you're checking return values as much. Still, I agree that result<void> is as easy to forget about as an int return code, and propagating errored outcomes up the call stack is unavoidably manual (though macro helpers make it a one line exercise). It's still vastly more powerful and convenient to write than int error code returns a la C, and future clang-tidy tooling can help out a lot on avoiding mistakes unlike C int error code returns which could mean anything, and therefore cannot be AST rewritten.
Something missing from the discussion so far is that expected/result/outcome MUST throw exceptions! If you try to fetch a value from a result and it contains an error, there is no alternative to throwing an exception. Yes there is one, to don't try to obtain the value directly with a get/value function. If you don't want to use exceptions, you should use visitation, functor/monad interfaces which are always safe.
No need to write anymore neanderthal code like if(error) ;-) Vicente