Subject: Re: [boost] expected/result/etc
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-02-09 15:04:44
On Tue, Feb 9, 2016 at 1:16 AM, Niall Douglas <s_sourceforge_at_[hidden]>
> 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.
> 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.
Lots of adjectives, perhaps we should discuss each one of them? :)
The use of error codes in low level APIs is a fact of life, since most of
that code is written in C anyway. I wouldn't call it optimal in C++, I
personally convert error codes into exceptions at the earliest possible
opportunity. As for runtime overhead, like I said already, where it matters
it can be easily deleted, by inlining; and, in such contexts you need to
inline with or without exception handling: I've never seen a case where I
could afford the overhead of a function call but could not afford the
exception handling overhead in the same function.
It feels strange to have to defend the use of exceptions for reporting
errors in C++, on the boost development board of all places. There are many
other advantages, for example when returning errors there is no such thing
as error-neutral contexts in your program, which increases coupling. Yes,
in some contexts one can't afford to use exceptions, but all general
complains that exception handling causes performance or any other problems
are theoretical, at best.
> 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.
Could you prove anything mathematically in the presence of side effects and
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk