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

Replace anyhow with proper error types #2741

Open
matthiasbeyer opened this issue Sep 22, 2024 · 2 comments
Open

Replace anyhow with proper error types #2741

matthiasbeyer opened this issue Sep 22, 2024 · 2 comments

Comments

@matthiasbeyer
Copy link
Contributor

anyhow is for application error handling, please replace it with dedicated error types in your library crates, so users of these crates can do sane error handling.

@flub
Copy link
Contributor

flub commented Sep 23, 2024

Could you be more specific to which error return values you would like to match on for different failure cases?

In general you are right, and as iroh moves towards 1.0 we probably also should migrate to more specific error types. On the other hand we really need this to be guided by application needs rather than enumerate all the current failure types, as that would lead to breaking the API on every release. If we were to use a custom error type right now things would probably be a single opaque error type, which is just like anyhow, but worse.

So far in our own uses we have not needed to distinguish error types, but this doesn't mean there isn't a need! This is why to move this forward we really need specific APIs with specific usecases called out for needing a custom error type. We'd really appreciate your input on this.

@matthiasbeyer
Copy link
Contributor Author

So I am just starting out using iroh, and only because IPFS is not usable in Rust, because there is no machine-readable API specification that I can program against.

So all of what the following refers to is very much hacked together in a short time, so take everything with a grain of salt please.

My error type in my application (or rather, in the library that becomes my backend implementation), looks like this:

#[derive(Debug, thiserror::Error)]
pub enum Error {
    #[error("Creating Node")]
    CreatingNode(#[source] anyhow::Error),

    #[error("Spawning Node")]
    SpawningNode(#[source] anyhow::Error),

    #[error("Failed to get reader")]
    GettingReader(#[source] anyhow::Error),

    #[error("Failed to put blob")]
    PutBlobError(#[source] anyhow::Error),

    #[error("Shutdown failed")]
    Shutdown(#[from] anyhow::Error),

    #[error("Error while serializing metadata to JSON")]
    SerdeJson(#[from] serde_json::Error),

    #[error("Error while adding bytes")]
    AddingBytes(#[source] anyhow::Error),

    #[error("Error while reading bytes")]
    ReadingBytes(#[source] anyhow::Error),

    #[error("Error while putting content object")]
    PuttingContent(#[source] Box<Error>),

    #[error("Error while putting metadata object")]
    PuttingMetadata(#[source] Box<Error>),
}

Maybe that helps a bit. As you can probably see from the variant names, half of the cases above are just wrapping errors your API returns. The rest is my application logic errors, that again wrap anyhow::Error because the underlying APIs of yours.

Remember, I am pretty much in the "sketch things up" phase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

2 participants