Skip to content

Consider hiding error internals #1143

@Kixunil

Description

@Kixunil

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    1.0Issues and PRs required or helping to stabilize the APIAPI breakThis PR requires a version bump for the next releasebrainstormerror handlingIssues and PRs related to error handling, mainly error refactoring epic

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions