Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-06-06 02:35:13
On 5/06/2017 11:08, Peter Dimov wrote:
> The correct approach here, I think, is not to define fat error
> codes, but to return an outcome whose error() is the error_code and
> whose exception() is the appropriate filesystem_error exception,
> complete with the path(s).
This sounds like the design I was suggesting in the "to variant or not
to variant" thread.
On 6/06/2017 02:46, Peter Dimov wrote:
> Vicente J. Botet Escriba wrote:
>
>> Oh, in this case it is clear that result<T> is not enough. We need
>> expected<T, filesystem::error>
>> where filesystem:error contains the error_code and the path.
>
> I don't find this particularly appealing, because the whole point of
> std::error_code was to avoid the need for each library to define
> separate error classes. expected<T, filesystem::error> will work, I'd
> just not be willing to recommend it as a general solution.
Is it more attractive if perhaps we had a result<T, E> where E was
constrained to a type derived from std::error_code? (I'm imagining a
sort of orthogonal hierarchy with types derived from std::exception,
although not for error-identification purposes, just to carry additional
data payloads.) Implicit slicing would allow this to be used
generically in contexts where an error_code is expected.
The error_code design is a little unfortunate since users are encouraged
to pass them around by value, which would slice off additional context
information. OTOH even if passed around by reference so the information
is preserved, it wouldn't be readily accessible without dynamic_casts.
(The same is true for exceptions as well, but some language/compiler
conspiracy hides this.)
The idea of error_code having an arbitrary error-info pointer seems
attractive, but the above semantics would probably require it being a
shared_ptr<void>, which would probably annoy everybody for various
reasons (including type safety, atomics, and memory allocation).
Niall's error_code_extended is a sort of half-way point where it
provides some additional fixed data payload which is probably useful in
many cases as a compromise type; additionally defined as POD to avoid
dynamic allocation and so that the ring buffer stomping over the data
doesn't upset too many things. It's a good idea, and I'm not sure if we
can come up with something better (other than arguing about what members
it should have), but perhaps there are some other possibilities to consider.
Perhaps rather than allowing arbitrary Es we could have a single E that
still provides some additional flexibility:
template<typename EI>
struct error_code_info : public error_code
{
// ...
const optional<EI>& error_info() const;
// ...
optional<EI> m_error_info;
};
template<typename T, typename EI>
using result = expected_impl<T, error_code_info<EI>>;
(Again, just a sketch to present an idea; don't get too hung up on the
specifics.)
Could something like this work? An error can be specified with an
arbitrary data payload, and yet consumers could just slice that off and
treat it as a plain error_code if they want. Meanwhile the
result/expected implementation can rely on noexcept/move guarantees
provided by error_code_info.
The main complication I see with this is that you probably don't want to
over-constrain the EI type, to simplify usage -- that's why I suggested
it store optional<EI> rather than EI directly, so that error_code_info
could be noexcept in all cases; if EI doesn't have noexcept move/copy
then error_code_info just discards the info if EI's constructor throws.
(So this does allow an empty state and the empty state should not be
considered weird; consumer code just needs to tolerate that like they
would any other optional<>.)
This does mean that consumers can introduce memory allocation into their
error codes (probably via std::string), which some people won't like --
but this leaves the choice of doing that or avoiding that up to them
(and the libraries they choose to consume).
The main downside I see of this is that it's less straightforward to
pass around error_code_info<EI>s than error_codes, but since this should
be mostly confined to a well defined call chain (with specific concrete
EI values rather than generics) I hope this wouldn't be a problem in
actual practice. (Using a shared_ptr<void> would avoid that issue but I
think that's probably worse overall.)
It might also result in a proliferation of EI types (as each method of
each library could conceivably define a unique one) but again I doubt
that should be an issue in practice.