How to handle errors occurring in combinator closures?

[closed]

If I were writing the following using a for loop to iterate the DirEntries, I'd use the ? operator to return a Result::Err from do_something_with_files.

But using combinators, the closure definitions don't allow this (hence the use of unwrap())

Is there a way to do an early return from the outer function with an error result (rather than panic-with-unwrap) in this context?

fn do_something_with_files(dir_path: &str) -> Result<Vec<String>, std::io::Error> {
    let result = read_dir(dir_path)?
        .map(|entry| entry.unwrap())
         // closure in  2nd map 
        .map(|file_name| some_function(file_name).unwrap())
        .collect();

    Ok(result)
}

fn some_function(keyword: &str) -> Result<&str, std::io::Error> {
    // something happens to return a Result::Err here
}

[H2CO3]

You probably want and_then() instead of map().

[alice]

Take a look at this.

[closed]

@alice - Perfect. Result's FromIterator implementation does just what I need.

My next question was going to be how I can collect up a subset of possible errors to report on, rather than always early return - I think partition() can help me there.

Thanks.

[closed]

Cheers - I did have a try with and_then but couldn't make it work for this situation. I am very new to Rust though, so may well have missed something obvious. Anyway I have a solution for now.

[H2CO3]

Oh, indeed. I was focusing too much on the title – the closure is apparently not where your problem was. I should've read the code more carefully.

[alice]

As for using and_then together with short-circuiting, take a look at this playground.

[closed]

Thank you, that's helpful. As a pretty experienced programmer in a number of languages I scoffed at the general view that Rust can be difficult. I expected to be substantially productive in a week. But .. I'm not. It's more challenging than I expected!

[Yandros]

@closed

My next question was going to be how I can collect up a subset of possible errors to report on, rather than always early return - I think partition() can help me there.

@https://docs.rs/itertools/0.8.0/itertools/trait.Itertools.html#method.partition_map

fn partition_map<A, B, F, L, R>(self, predicate: F) -> (A, B)
where
    Self : Sized,
    F : Fn(Self::Item) -> Either<L, R>,
    A : Default + Extend<L>,
    B : Default + Extend<R>, 

Collect all iterator elements into one of two partitions. Unlike Iterator::partition, each partition may have a distinct type.

Example

use ::itertools::{Itertools, Either};

let successes_and_failures = vec![Ok(1), Err(false), Err(true), Ok(2)];

let (successes, failures): (Vec<_>, Vec<_>) =
    successes_and_failures
        .into_iter()
        .partition_map(|r| match r {
            | Ok(v) => Either::Left(v),
            | Err(v) => Either::Right(v),
        })
;
assert_eq!(successes, [1, 2]);
assert_eq!(failures, [false, true]);

• (technically predicate does not need to be Fn; FnMut would suffice)

[closed]

@Yandros - spot on, thanks. Aside from its use just as a library, it looks like the Itertools codebase might be a good resource for learning more about iterators.