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

Reconsider use of error handling crates #14

Open
pulsastrix opened this issue Jun 26, 2024 · 0 comments
Open

Reconsider use of error handling crates #14

pulsastrix opened this issue Jun 26, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@pulsastrix
Copy link
Member

pulsastrix commented Jun 26, 2024

Is your feature request related to a problem? Please describe.
Currently, our error types do not use external crates, which forces us to implement traits such as Display manually and adds a lot of boilerplate code.
This was unavoidable, as the Error trait that most error handling libraries are based on was part of std up until recently, which prevented using them in no_std environments.

Describe the solution you'd like
As the Error trait will be moved to core with the next stable Rust release (rust-lang/rust#103765) and will therefore be available in no_std environments, we should reconsider the usage of error handling crates in order to remove some boilerplate.

As thiserror is one of the most widely used rust crates for this purpose, it would make sense to use it as soon as it also supports no_std (dtolnay/thiserror#304).

Describe alternatives you've considered
We could also keep the existing code and not switch to thiserror.
This would allow us to keep supporting older Rust versions (using thiserror with no_std would probably require a MSRV bump to 1.81), but we will have to maintain our error types manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants