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

Remove failure crate in favor of thiserror #12

Open
cbourjau opened this issue Apr 15, 2022 · 2 comments
Open

Remove failure crate in favor of thiserror #12

cbourjau opened this issue Apr 15, 2022 · 2 comments

Comments

@cbourjau
Copy link
Owner

cbourjau commented Apr 15, 2022

When this project was started failure was the way to go. However, time has moved on and the current recommendation for error handling seems to be thiserror. It would be nice to update all crates in this project to the latter. See #9 (comment) for some recent discussions on this topic.

@strangeglyph
Copy link

Some additional thoughts: I believe we could leave failure in for the non-library crates. The structured information thiserror provides is most useful for library consumers. For applications we can provide the same information as text to the user.

@cbourjau
Copy link
Owner Author

I think the commonly recommended library for applications is anyhow which depends on thiserror. I think its fine to only migrate some of the sub-crates for now, though, and leave others still on failure.

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

No branches or pull requests

2 participants