Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-02-09 04:16:34

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. 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.

I would therefore not draw as thick a line between the two approaches 
as some here are doing. For systems programming where you are a thin 
veneer around OS calls a 98% result based noexcept programming style 
is the optimal way of doing this sort of C++ programming - tiny 
runtime overhead, powerful abstraction over C error code programming, 
highly maintainable and extremely amenable to static analysis to 
catch logic errors. With just a little extra libclang tooling (some 
of which I plan to write) this style idiom ought to be mathematically 
provable as correct in the functional programming sense, which would 
be cool, not least for those programming nuclear reactors etc.

The further you get away from errno/GetLastError() though the more 
you end up exclusively on C++ exceptions which is no bad thing. Large 
teams of engineers make better code more cheaply when the language 
does exceptions, though the skills demands of writing exception safe 
C++ is non trivial. Still, as one can see in LLVM's universal 
exception handling framework, C++ exception throws ought to 
seamlessly convert into other LLVM based languages, so potentially a 
big future win there: write just enough in C++, write the rest in 
some language average programmers do better with, both layers 
seamlessly work together.

Niall

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