Refactoring: use anyhow
for all internal error handling and propagation, but use a final Error
for API
#3
Labels
anyhow
for all internal error handling and propagation, but use a final Error
for API
#3
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 finalError
for the public API.Notes:
anyhow
first, see how usingcontext
can be cool and nice for "attaching" error informationResult
types toanyhow::Result
, this is supposed to be easyAPI
and use anstd::Result
. this means you need to now convert fromanyhow::Result
to a standard one. you can use the existingthiserror
library to do thatThe text was updated successfully, but these errors were encountered: