nrc
Collected feedback
I'm using this issue to collect feedback from various places after initial publication
From https://github.com/nrc/error-docs/pull/10: need to better explain the error conversions in the error type design chapter
From Twitter: type Result<T, E=mod::Error> = std::Result<T, E> as a better version of the recommended alias
From Twitter: more examples (pointing at public repos), concrete examples of what the libs in the ecosystem chapter do.
From Reddit: impl From is part of API, mapping from Anyhow features to std features, error-stack crate, good feedback from matklad and epage.
From Teams: The error variant might increase the size of return types, affecting perf. Consider size of error types and/or Box it.
Add a sentence of explanation about try blocks to explain why all three ?s are necessary
Verifiers can detect panics, e.g., Prusti, Kani
More 'convenience links' for crates, etc.
Link to Joe Duffy's blog post on the error model. Emphasis on recoverable errors vs program bugs earlier on, i.e., don't present panicking as an option for error handling.
And from Zulip: add a case study on designing an error hierarchy, specifically discourage the single, monster enum anti-pattern.
Could probably improve the description of UnwindSafe.
Check for any mentions of Error::chain (which is now sources)
Mention Snafu crate
And continuing the discussion on designing error hierarchy:
"SNAFU has long recommended making one per module with a throw-away line of "or more" and I've been mulling more aggressively recommending more."
"I've been phrasing it as "you should have an error type for each domain/responsibility in your code", purposefully avoiding saying "module". and that if you have lots of _ => unreachable!() branches that's a sign you should split up errors. Which seems to click for people."
"As an extreme example, I have a library that works with FFI using C-style return codes. The underlying library reuses the same set of ~15 codes for all possible methods, but each code can have a different implication for each method (e.g. ERR_BUSY might mean the receiver hasn't gotten ready post-creation in one case, while in another it means the receiver is already doing something). So I actually have an enum for each method (roughly) with the relevant error codes for that method plus a better contextual description of what they mean in the Display impl."