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.
Currently, the
Errorenum 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
Errorvariants, especially if the error originates in another library that provides its own error types. The error values can still easily be converted to strings usingDisplay/ToStringwhen they need to be shown to the user, but they can also be interpreted by code.thiserroris helpful for concisely implementing all the related traits.