Equivalent of map_err that uses from_error automatically

Question

Result has an map_err function that allows you to map Result<T, E> to a Result<T, F> by applying a function to the error value.

For types that implement FromError, the most natural function to apply would just be FromError::from_error, leading to something like the following:

foo() .map_err(FromError::from_error) .and_then(|val| { val.do_something().map_err(FromError::from_err) })

It seems that for this kind of use case, there should be a less cumbersome method defined on Result<T, E> where E: Error that calls FromError::from_error less verbosely, something like the following but with a better name:

foo() .wrap_err() .and_then(|val| { val.do_something().wrap_err() })

This would just be equivalent to .map_err(FromError::from_error), simply shorter and more convenient for when you're doing this kind of method chaining.

Is there something like this defined anywhere? I could not find it, though I'm not sure if I was looking in all of the right places in the documentation.

This question was inspired my my answer to this one, in which I described both FromError for use with try! but realized it didn't help with the method-chaining style being used there.

you might be interested in the ? postfix operator: github.com/rust-lang/rust/pull/23040 — oli_obk
– oli_obk, Commented Mar 13, 2015 at 7:22
@ker Interesting, I hadn't seen that. That operator seems to just be syntactic sugar for try!, which interrupts control flow to return if you see an error value, while the wrap_err method that I describe propagates the error through the chained method calls. That may be what is more useful in a wider variety of cases, but there are cases where getting a Result from chained method calls without interrupting your control flow may also be useful. — Brian Campbell
– Brian Campbell, Commented Mar 13, 2015 at 15:38

Chris Morgan · Accepted Answer · 2015-03-13 01:06:00Z

There is no such method at least at present. I believe that in practical situations try! is used somewhat more commonly than the method chaining approach (and it tends to yield nicer code in my opinion), so it’s not been such an important consideration.

Potentially more interesting as a design consideration would be changing and_then et al. to use FromError:

pub fn and_then<U, E2: FromError<E>, F: FnOnce(T) -> Result<U, E2>> (self, op: F) -> Result<U, E2> { match self { Ok(t) => op(t), Err(e) => Err(FromError::from_error(e)), } }

… but I don’t believe this will happen, because they’re marked stable and it would be a just slightly backwards-incompatible change.

That's true, this would become even more convenient if and_then did this automatically. I think you would need to call op(t).map_err(FromError::from_error) in the Ok case as well.
Actually, would it be backwards incompatible? There's a catch-all impl<E> FromError<E> for E so that all types implement from_error to themselves as the identity function, so for all existing code that uses and_then where both error types are the same, the types would work out and the FromError calls would just do nothing (and hopefully be optimized out). Is there a way in which that would not be considered backwards-compatible?
It would be slightly incompatible because some generic combinations that can be resolved uniquely at present would no longer be able to be resolved uniquely.

Collectives™ on Stack Overflow

Equivalent of map_err that uses from_error automatically

1 Answer 1

3 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Linked

Related