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/