Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-02-11 06:47:25

On 11 Feb 2016 at 1:19, Michael Marcin wrote:

> > 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. This fact is why I don't worry about static
> > function initialisers and just go ahead and use
> > error-code-via-system_error throwing constructors, ultimately you
> > need try...catch in there one way or another.
> >
> 
> There most certainly is an alternative!
> I certainly don't want this behavior.
> 
> There's no way that accessing the value of a result<T> without checking 
> for an error is not a programming error.
> It should be a precondition that to access the value it needs to not 
> contain an error.
> It should *not* be throwing an exception because you cannot fail to 
> satisfy the postcondition until you meet the preconditions.
> 
> Undefined-behavior is the appropriate specification for accessing a 
> value from a result that contains an error.

This is easy to say, but I wouldn't be happy with simply documenting 
"all bets are off if you do this" because it's very easy to do 
accidentally. Really I want some method of trapping it at compile 
time.

The reason Outcome currently throws an exception when trying to get() 
from an errored/excepted outcome is because I don't know how to get 
it to refuse to compile instead, and the next best alternative of 
refusing to link is extremely non-descriptive (specifically it tells 
you absolutely nothing about where in your code the unchecked get() 
is being performed). Rather than implement something distinctly 
unhelpful I've left it as is for now.

However rest assured Outcome will eventually work as described with 
RTTI and exceptions off just as AFIO v2 will. Right now it doesn't, 
but it's my first todo item after the ACCU conference in April and 
Outcome was deliberately designed to work perfectly with RTTI and 
exceptions off, it just currently fails due to minor unfinished 
problems like the above mentioned as I felt I need a lot more 
reflection time on what to do to fix them properly.

And between now and then, simply always check your return before 
get() and the compiler will elide any potential exception throw e.g.

outcome<int> _foo; // contains some value
int foo;
if(_foo) foo=_foo.get();
foo=_foo.get_or(5); // also works

If compiled with optimisation you should see no exception throwing 
code emitted.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/