Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Jonathan Müller (jonathanmueller.dev_at_[hidden])
Date: 2018-02-01 12:03:50

On 01.02.2018 12:10, Andrey Semashev via Boost wrote:

> 
> The important difference between using exceptions and error codes (or 
> Boost.Outcome, I presume) is that in case of exceptions the user has to 
> make an effort to write broken code and the correct code most of the 
> time comes naturally, while with manual error checking it is the other 
> way around. This is the reason why manual error checking is more prone 
> to mistakes in error handling.
> 
> PS: All that, of course, is given that RAII is ubiquitous. If it's not 
> then error handling is difficult regardless of the tool you use.
> 

This entire mistake would have been prevented, if a proper return type 
was used, for example a sane optional (that doesn't try to be a pointer):

static optional<A> A::create(…) {…}

Then, this will not compile:

auto a = A::create(…);
a.foo(); // error!

So, you're forced to write:

a.value().foo();

And accessing the value on an optional without checking it should always 
be a red flag and not just written "naturally" (That's why operator-> 
for optional is a mistake IMO).

Yes, it's still prune to mistakes, but so are exceptions, it's just a 
little bit more work:

Foo::Foo()
{
    try
    {
        my_a = A::create(…);
    }
    catch (…)
    {
        log_error();
    }
}

Foo::bar()
{
    my_a->foo(); // ups?
}

So I won't necessarily say that manual error handling is more error 
prone, with properly designed facilities (and a little language support) 
it can be as good as exceptions (just look at Swift: it provides syntax 
sugar for error output parameters).