-
Notifications
You must be signed in to change notification settings - Fork 158
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
Comments
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. |
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 Remember, I am pretty much in the "sketch things up" phase. |
Hey @matthiasbeyer, great to see you back after our last encounter, Last we spoke, the team came to the working conclusion that we'd stick with anyhow pre-1.0, and transition to
Which means (unless others, especially @dignifiedquire disagree): we need to figure out when to transition over to |
If the rewrite can happen in a day, would it happen earlier? What's blocking it from happening now? Just looked at the source code. There are 146 invocations of Are there any other ways where one can craft a unique Then it goes on Crowdin, or some other place for translation. |
Yes. There is this implementation: So everywhere
There might be even more issues where code has to be re-achitected when something was assuming just Unfortunately it's a little more involved than replacing |
This is the way to go. So the immediate plan looks like this:
Then, we split the 146 variants into different sub errors, or have
The above design is one error. Breakage is unavoidable. Any other concerns? One thing I can think of is that different libraries, e.g. |
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.
The text was updated successfully, but these errors were encountered: