Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-02-02 01:29:26
On 1/02/2018 19:55, Emil Dotchevski wrote:
> This does not protect the user at all:
>
> std::unique_ptr<A> a=A::create();
> a->foo(); //undefined behavior
Sure, but you can always write daft code. If you are aware that it is
legal for A::create() to return nullptr (and you should be aware,
because it will be documented), then the above would be an obvious bug,
and you should replace it with:
if (auto a = A::create())
{
a->foo();
}
This is *much* more obviously safe than your suggested exception-enabled
code, where you have to have external knowledge (that it will throw on
failure and cannot ever return nullptr). And it's trivial to add logic
for the failure case in an else block, vs. the more wordy try-catch.
(Even if you don't know whether A::create() is supposed to be able to
return nullptr or not, it is usually more sensible to defensively write
the code as if it could, since it is a legal value of the return type,
regardless of whether exceptions are enabled or not.)
Granted, exceptions are better at telling you *why* it failed, which the
above can't. And exceptions are better at hiding the error-handling
paths for the cases where errors are expected to be exceptionally rare
(pun intended), which can make the "real" logic not get lost in a maze
of error-handling. Most people appreciate that -- but sometimes having
explicit error paths is useful too.
Nobody is forcing you to stop using exceptions, or even encouraging the
majority of applications to stop using them. Outcome just provides a
way to add back a little (or a lot, as needed) explanation to failure in
cases where someone has already decided they can't or don't want to use
exceptions for whatever reason -- especially when failure is expected,
not unusual (I think everybody agrees that exceptions-as-control-flow is
not good code design, right?).
> This is not an advantage over using exceptions, and besides it is only true
> in the simplest of cases. The problem is that Outcome requires users to fit
> any and all possible failures into a single error type, which is not always
> possible. In general, you can neither enumerate nor reason about all
> failures which may occur. Notably, the one Outcome feature that can deal
> with this problem is its ability to transport std::exception_ptr. :)
One error type per context. You can have completely different error
enumerations per method if you really want to, although it would
probably be more common to have one error domain per library, or just
use the closest approximation from a standard set, like POSIX errno. Or
use error_code, which allows relatively seamless interoperation with all
of these.
Exceptions are actually a relatively poor method for transporting errors
that need to be *reacted* to. (Not so much through any fault of
exceptions themselves, but rather through common usage thereof.)
In most code, the best you can do with them is catch them in some
central place and log them for some developer to look at later. Too
many methods just throw one of the standard types like
std::runtime_error without defining custom subclasses or adding anything
more programmatically useful beyond the text message -- which in itself
can be a problem for multi-lingual applications, especially where the
thread that generated the exception is running in a different language
context from the developer and/or user.
At least an error code is inherently an abstract thing that you know you
need to look up a translation for at the last moment when actually
presenting it to the user, or that logic can easily say "in this
context, I was expecting that and I know how to deal with it".
Sure, it's possible to add error codes and extra data fields to
exceptions and allow the message to be constructed later from these
pieces. And it's not possible to do this with error_code alone. But it
will be possible to do this with Outcome. (And most people don't do it
anyway, no matter the error transport.)