Show source by default, add feature to hide it #60
Conversation
schneems
force-pushed
the
schneems/un-hide-error
branch
from
d3976cd to
45d3b10
Compare
close andrewhickman#59 Changes the default behavior so that the output in the readme now matches the output a user would see when they use the library. Specifically, it now includes the original `std::io::Error` in the output. It introduces a feature `anyhow`. By default: - By default: fs-err will include `std::io::Error` in the Display output, and return `None` from `Error::source()` - With `anyhow` fs-err will not include std::io::Error in the Display output, and return `Some(std::io::Error)` from `Error::source()` This is based on the guidance from andrewhickman#51. That discussion links to this 2020 discussion rust-lang/project-error-handling#23 that suggests that you should either print the source and return `None` from `Error::source()` (https://doc.rust-lang.org/std/error/trait.Error.html#method.source) or not print anything and return `Some(E)`. This allows users of anyhow (or similar) libraries to configure fs-err for the behavior they desire, while not hiding information by default from unsuspecting adopters that are not using those libraries. It optimizes for the case of accidentally showing extra information that a user can then investigate and disable, rather than hiding information that the user might not realize is missing.
I discussed the logic here andrewhickman#59 (comment). The prior suggested name "anyhow" was a little too specific/esoteric and in the event that the feature flag outlives the popularity of `anyhow` it wouldn't make sense. This suggested name tries to focus on the behavior outcome of the feature. It empowers callers to format the "called by" information however they want by: - Providing a source of that data (Error::source) - Not formatting emitting that data in `Display`
schneems
force-pushed
the
schneems/un-hide-error
branch
from
45d3b10 to
7c1df0a
Compare
|
I'm leaning towards of |
At a glance it's not clear why that logic exists based solely on the feature name. Adding a doc here clarifies the intent.
|
I think that's a pragmatic choice. I updated the PR with that wording. My only concern would be someone mistaking the intent when developing internally. To that end, I added a comment explaining it inside of the |
| }?; | ||
|
|
||
| #[cfg(not(feature = "custom_caused_by"))] | ||
| write!(formatter, " caused by: {}", self.source)?; |
There was a problem hiding this comment.
I think I prefer just seperating the original error with a colon, i.e.:
failed to open file `notfound`: The system cannot find the file specified. (os error 2)
to avoid confusion in case this gets printed as part of an anyhow error message
There was a problem hiding this comment.
Sorry. I didn't see this comment until after it was merged. I've been checking the PR. I see it was made 4 days ago, maybe it was in a pending review state or maybe github had a hiccup?
Either way. I also see you merged it and made the change yourself, which is perfectly fine with me. Thanks again
close #59
Changes the default behavior so that the output in the readme now matches the output a user would see when they use the library. Specifically, it now includes the original
std::io::Errorin the output.It introduces a feature
anyhow. By default:std::io::Errorin the Display output, and returnNonefromError::source()anyhowfs-err will not include std::io::Error in the Display output, and returnSome(std::io::Error)fromError::source()This is based on the guidance from #51. That discussion links to this 2020 discussion rust-lang/project-error-handling#23 that suggests that you should either print the source and return
NonefromError::source()(https://doc.rust-lang.org/std/error/trait.Error.html#method.source) or not print anything and returnSome(E).This allows users of anyhow (or similar) libraries to configure fs-err for the behavior they desire, while not hiding information by default from unsuspecting adopters that are not using those libraries. It optimizes for the case of accidentally showing extra information that a user can then investigate and disable, rather than hiding information that the user might not realize is missing.