Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-02-09 11:50:01

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