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

Use semantic error values #27

Open
Xiretza opened this issue Apr 23, 2022 · 1 comment
Open

Use semantic error values #27

Xiretza opened this issue Apr 23, 2022 · 1 comment

Comments

@Xiretza
Copy link
Contributor

Xiretza commented Apr 23, 2022

Currently, the Error enum is little more than a string along with a broad error category. This makes it effectively impossible to analyze and react to these errors programmatically, as this would require parsing error messages that are subject to change at any time. Additionally, a lot of information is simply discarded this way (depending on how the string is constructed).

A better solution would be to store semantic types in the Error variants, especially if the error originates in another library that provides its own error types. The error values can still easily be converted to strings using Display/ToString when they need to be shown to the user, but they can also be interpreted by code. thiserror is helpful for concisely implementing all the related traits.

@tasn
Copy link
Member

tasn commented Apr 25, 2022

Yeah, I'm open to having better errors. It was just a quick way to not have to worry about how to structure the errors.

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

No branches or pull requests

2 participants