Obtaining a & to an error

[alexanderlinne]

Hello,

is there any way to get a reference to the error within a cpp::result?

[bitwizeshift]

Hi @alexanderlinne, good question. The short version is no, not currently -- but this is by design.

The main reason for this is that I didn't want result to simply be a generic either<T,E>-style wrapper, which is otherwise just a more specialized version of a variant. I wanted result to be semantically meaningful -- where it either contains a result and some form of error code (in this case, a non-error), or just an error code. I also wanted to reduce the number of cases where an error could occur; and returning by-reference would make both value() or error() become potentially exceptional-(or aborting)-paths.

In general, error types are meant to be lightweight; either integer values, std::error_code/std::error_condition, std::exception_ptr, etc -- and so the cost of this by-value return should be negligible in practice. In the case that no error is contained, it performs a default-construction -- which also follows the above types to produce non-error style values: std::error_code{} produces a non-error state, std::exception_ptrproducesnullptr(no exception). This means in the value cases,error()` can be tested and determined to not contain an error.

What is the particular case you are working with that references would be a better fit? I'm open to suggestions for improvements if this is an important feature.

[alexanderlinne]

Hi @bitwizeshift,

what I'm working with is actually an error type which is not lightweight. Instead it contains detailed error information any may contain a stacktrace. The particular case is a piece of code where I want to inspect what particular error was returned (given has_error is true) and to then pass on the complete result. With the current API the only efficient way to do that would be to move the error out of the result and then construct a new result.

Would you be open to accept a PR that changes the result of error to a reference type?

[bitwizeshift]

I have been in a similar situations in one of my own codebases with a larger error object; though I solved this through an extra layer of indirection by creating an error_handle type that contains either a unique_ptr or shared_ptr to the error data. Is something similar to this a possible workaround for the situation you are experiencing?

This result implementation was designed with the idea that error states are meant to be light-weight. A handle like this makes it easy to return error() and not care for the cost of the copy (which for a handle using shared_ptr, would just be a couple pointer copies and an atomic increment).

Would you be open to accept a PR that changes the result of error to a reference type?

I'm open to accepting a PR for a means to extract a reference to the internal error, but I'm not sure if I'd like to achieve this by having error() itself return a reference. My preference is to preserve error()s current behavior, but possibly offer an alternative to extract it for cases like you're describing.

The original design goal that I was aiming for was to limit the number of places where result itself could fail, since result is intended to represent fallibility. Basically I wanted to avoid having both value() and error() causing exceptions when in the wrong state -- especially since the latter of which becomes a bit more awkward to handle. Unlike value(), which can throw an exception containing the current error-state (effectively transforming an error-code into an exception), there isn't a natural way to convey what error() throws.

The way the std::expected proposal satisfies this was to throw a std::bad_expected_access<void> specialization for no values, and for std::bad_expected_access<T> to inherit from this type. IMO this is not a particularly nice or coherent approach, since the specialization doesn't model the primary template at all (there is no unexpected value to access in the void state). This is why the approach I took was to represent default-constructed state as being the "null" error state (e.g. no bad value, a "0" error code). This makes the error behave like a status check, meaning the status is always present. With error codes returned by value, this drops the need for error() to be a failure case if an error is not contained.

---

I'm open to suggestions and/or a PR for extracting a reference to the internal error, but I'd prefer an approach that does not alter error() itself. If the new function returns a reference, then there will be a need for some error handling (e.g. an exception or something) -- which I'm not against, but I would like to try to find something more coherent than what the std::expected proposal does.

My first thought would be to offer this as a non-member function so that it's not the primary way for users to access the error. This would minimize the impact of failure cases when used in the wrong state (as mentioned above). Perhaps something similar to what any_cast does:

// Throws some new 'bad_result_error_access' exception if no error contained
auto get_error(result<T,E>& r) -> E&;
auto get_error(result<T,E>&& r) -> E&&;
auto get_error(const result<T,E>& r) -> const E&; 
auto get_error(const result<T,E>&& r) -> const E&&;

// Returns null if r is null, or if r does not contain 'E'
auto get_error(result<T,E>* r) -> E*;
auto get_error(const result<T,E>* r) -> const E*;

What are your thoughts?

[alexanderlinne]

I actually think your first thought is correct, using a std::shared_ptr to the error object might be the ideal solution. Keeping the Error type small also means that the return type of functions using the Result type remains as small as possible. Given that the error type itself is already costly to create, the overhead of a std::shared_ptr should be negligible.

Thanks for you input. :)