3 ms·
In my personal experience distinct handling of errors like these does indeed come up significantly more rarely. What ends up mattering to me much more often is
by nagisa 5y ago
In my personal experience distinct handling of errors like these does indeed come up significantly more rarely. What ends up mattering to me much more often is how these errors are presented to the user, or what ends up in the logs in production. In those cases something like
error: failed to read contents of `foo`
caused by: a physical I/O error has occurred (...)
and
error: failed to open `foo`
caused by: permission denied (...)
are significantly more actionable than just the underlying I/O errors by themselves. To the point where a person reading these messages has a shot at addressing the problem without any prior knowledge of the code base.
In `anyhow` adding such context via its `context` family of methods seems fairly well accepted. I hope that my comment demonstrates there's no reason why `enum` based approach would need to be any worse than what `anyhow` can achieve.
- Macha 5y agoFor your logs you're going to print the error's default message anyway, so you should have the underlying message of the std::io::Error as long as it's listed in the source of your wrapped error.
- shepmaster 5y ago> you should have the underlying message of the std::io::Error This is a point of debate[1] among the error-handling working group. [1]: https://github.com/rust-lang/project-error-handling/issues/44 https://github.com/rust-lang/project-error-handling/issues/4...
- shepmaster 5y ago> how these errors are presented to the user, or what ends up in the logs in production. In those cases something like [...] are significantly more actionable than just the underlying I/O errors by themselves. To the point **where a person reading these messages has a shot at addressing the problem** without any prior knowledge of the code base. (emphasis mine) This is a huge belief of mine as well. I call it a "semantic stacktrace". I actually go as far as to say that _most of the time_ backtraces in errors are an antipattern, as it gives a false sense that an error is actionable ("oh, just look in the code!"). I even try to make it such that each leaf error is constructed in exactly one place so that grepping for the error identifies that one location.