Boost logo

Boost :

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at