-
Notifications
You must be signed in to change notification settings - Fork 965
Consider hiding error internals #1143
Copy link
Copy link
Open
Labels
1.0Issues and PRs required or helping to stabilize the APIIssues and PRs required or helping to stabilize the APIAPI breakThis PR requires a version bump for the next releaseThis PR requires a version bump for the next releasebrainstormerror handlingIssues and PRs related to error handling, mainly error refactoring epicIssues and PRs related to error handling, mainly error refactoring epic
Description
Currently most error types are enums with publicly-visible variants. This makes it harder to stabilize the crate because even simple changes like adding more information to the error would cause breakage. Proposed solution:
enum InnerError {
// variants
}
// relevant derives & such
pub struct Error(InnerError);Alternative applicable in some cases:
// We are 100% sure we will never-ever remove or rename any variant
#[non_exhaustive]
pub enum Error {
ErrorA(ErrorA),
ErrorB(ErrorB),
// ...
}
pub struct ErrorA {
field1: Type1,
// ...
}
pub struct ErrorB {
// ...
}This makes it impossible to inspect errors which is quite inconvenient for use cases like error message translation but it seems the best approach is to try and see which features people actually need.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
1.0Issues and PRs required or helping to stabilize the APIIssues and PRs required or helping to stabilize the APIAPI breakThis PR requires a version bump for the next releaseThis PR requires a version bump for the next releasebrainstormerror handlingIssues and PRs related to error handling, mainly error refactoring epicIssues and PRs related to error handling, mainly error refactoring epic