Feature request: context() and with_context() on Result and Option

[danielparks]

I just switched from Snafu to thiserror, and on the whole my code has become a lot cleaner and clearer.

One thing that I miss is Snafu’s context() method on Result. It works much like the context() method in anyhow, but it allows adding structured context to an error. My current use case:

#[derive(Debug, Error)]
enum MyError {
    // . . .
    #[error("failed reading page {path:?}")]
    ReadPageFile { source: io::Error, path: PathBuf },
}

impl MyError {
    #[allow(non_snake_case)]
    fn ReadPageFileMap(path: &Path) -> Box<dyn FnOnce(io::Error) -> MyError> {
        let path = PathBuf::from(path);
        Box::new(|source: io::Error| MyError::ReadPageFile { source, path })
    }
}

fn read_from(path: &Path) -> Result<Page> {
    let raw = fs::read_to_string(path)
        .map_err(MyError::ReadPageFileMap(path))?;
    // . . .
}

Put more simply, I just want a convenient way to convert an io::Error into MyError::ReadPageFile while adding a path field to it.

[Luro02]

Here is the relevant method https://docs.rs/snafu/0.6.0/snafu/trait.ResultExt.html#tymethod.context

[Luro02]

Even though I would love to have such a convenient method, it doesn't seem to be in the scope of this crate. To quote from the documentation:

Thiserror deliberately does not appear in your public API.
You get the same thing as if you had written an implementation
of std::error::Error by hand, and switching from handwritten impls
to thiserror or vice versa is not a breaking change.

As you can see in the function signature for ResultExt::context of snafu there are a lot of traits in the signature, that are defined in the snafu crate. This means, that those traits appear in the public api.

[dtolnay]

Context selectors in snafu are great and the big selling point of the library. But as @Luro02 mentioned, it isn't a good fit for the design of this library.

Thanks anyway!