-
Notifications
You must be signed in to change notification settings - Fork 992
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
Return Result from methods of ChainAdapter #2722
Return Result from methods of ChainAdapter #2722
Conversation
Most of the methods return nothing or bool which is used to decide if a sender of a message should be banned or not. However underlying chain implementation may fail so we need a way to reflect this fact in API. Also it allows to reduce number of unwraps and makes the code more robust.
Concept Ack. I'm not in love with introducing a dependency from p2p to chain module for two reasons:
Is there an alternative approach -- can we move chain's error type to it's own module or maybe provide a module for cross-module errors (containing a enum with a variant for each module, whereas the |
@JeremyRubin I had the same feelings and tried different approaches, but haven't find anything more reasonable than just use We deal with I think we should tackle error management in a more holistic way, I created an issue to tack it a while ago #2542 and I had the same idea of error crate to rule them all. To be fair I don't think it's a right approach anymore, but not sure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mind fixing conflicts? I agree with the approach.
Most of the methods return nothing or bool which is used to decide if a
sender of a message should be banned or not. However underlying chain
implementation may fail so we need a way to reflect this fact in API.
Also it allows to reduce number of unwraps and makes the code more robust.