Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error-handling crates slide should be split #2027

Closed
fw-immunant opened this issue Apr 25, 2024 · 1 comment · Fixed by #2332
Closed

Error-handling crates slide should be split #2027

fw-immunant opened this issue Apr 25, 2024 · 1 comment · Fixed by #2332
Assignees

Comments

@fw-immunant
Copy link
Collaborator

We used to (in v1) separately show using thiserror (to remove the tedium of manually writing boilerplate From and Display implementations for custom error enums) and anyhow (to flatten error types and allow adding context to errors). Now we show them together, and it makes it harder to understand the value proposition of thiserror. In particular, the example does not demonstrate the #[from] attribute anymore and loses the ability to dispatch on error enums because it uses the erased anyhow::Result type.

We should split this slide back into two slides again so that we can separately address these separate concerns. thiserror provides convenience without changing semantics, while anyhow changes error semantics in a way that is mostly suitable for applications but not libraries.

@djmitche
Copy link
Collaborator

This sounds like a good idea!

@fw-immunant fw-immunant self-assigned this Aug 12, 2024
fw-immunant added a commit that referenced this issue Sep 20, 2024
`thiserror` is best understood as a way to eliminate boilerplate on the
patterns we've already seen, and then we can show it in conjunction with
`anyhow` subsequently.

Fixes #2027.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants