Consider allowing to discard the underlying error about snafu

[tjkirch]

I've also had times when I didn't want to expose the source error - because it would be confusing for the end user, or because I knew more than the source did about context and can actually provide better detail.

In those cases, I've used the pattern of source().ok().context(MyError) - in other words, converting Result to Option and using SNAFU's OptionExt instead of ResultExt. .ok() is nice and short, and requires you to explicitly throw away the source context, so I was happy with that. Maybe it's worth documenting?

[shepmaster]

in other words, converting Result to Option and using SNAFU's OptionExt instead of ResultExt. .ok() is nice and short,

Notably, it's shorter than my proposed function:

"42".parse::<i32>().ok().context(Parsing); 
"42".parse::<i32>().lossy_context(Parsing);

It also reuses existing concepts (Result::ok) instead of creating new SNAFU-specific concepts.

Perhaps this should just be documented in the cookbook.

[HenningTimm]

I am not sure if this is a good idea. If I understood this correctly, this would allow me to easily replace an error with a snafu-error (like shown above), instead of doing something like this:

match "42".parse::<i32>() {
    Ok(x) => Ok(x),
    Err(_) => Err(Parsing),
}

Having the option to do this sounds nice.
However, I am not sure if this incentivizes good error handling. While I have not yet come across this use case, I could imagine to use this for merging several errors. This could make it too easy to just shadow underlying errors, for example to replace errors from several parsing functions with just one parsing error.

On the other hand, it is already possible to do this (see above), so making it more ergonomic might help people. A line in the documentation that this should be used carefully should be enough.

[jamessewell]

This is useful when the underlying error is intentionally useless.

Example:

https://briansmith.org/rustdoc/ring/error/struct.Unspecified.html

An error with absolutely no details.

ring uses this unit type as the error type in most of its results because (a) usually the specific reasons for a failure are obvious or are not useful to know, and/or (b) providing more details about a failure might provide a dangerous side channel, and/or (c) it greatly simplifies the error handling logic.

So in this case all you know is that it's a CryptoError - you don't want the source because it's not only useless, it's actually quite confusing to bubble up.

[HenningTimm]

Intentionally useless errors to avoid side channel attacks. Fascinating.

In light of this use case, consider my concerns addressed.

[shepmaster]

Some people may also be interested in #78.