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

Refactoring: use anyhow for all internal error handling and propagation, but use a final Error for API #3

Open
jondot opened this issue Dec 3, 2022 · 0 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@jondot
Copy link
Member

jondot commented Dec 3, 2022

Suggestion / Feature Request

The various decompressors use a "central" error enum, which can convert from named and specific error types. Although this is the recommended and acceptable best practice, it makes for an overly verbose coding of an error ergonomics story.

anyhow will chain, wrap, errors, and encourage and allow for adding contexts, which is something we need here.
the only drawback of using anyhow in libraries is that we cannot expose any anyhow type in the public API.

This is why we suggest a refactoring: use anyhow for all internal error handling and propagation, but convert it to a final Error for the public API.

Notes:

  • get familiar with anyhow first, see how using context can be cool and nice for "attaching" error information
  • convert all Result types to anyhow::Result, this is supposed to be easy
  • locate all public API and use an std::Result. this means you need to now convert from anyhow::Result to a standard one. you can use the existing thiserror library to do that
@jondot jondot added enhancement New feature or request good first issue Good for newcomers labels Dec 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant