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

Return Result from methods of ChainAdapter #2722

Merged
merged 3 commits into from
Apr 8, 2019

Conversation

hashmap
Copy link
Contributor

@hashmap hashmap commented Apr 1, 2019

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.

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.
@hashmap hashmap added the task label Apr 1, 2019
@hashmap hashmap added this to the 1.0.3 milestone Apr 1, 2019
@JeremyRubin
Copy link
Contributor

Concept Ack.

I'm not in love with introducing a dependency from p2p to chain module for two reasons:

  1. what if these methods should return a different error type in the future
  2. it introduces a new dependency on a bunch of other stuff (including the keychain module)

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 From<MyModuleError> for AllModulesError wraps the serialized error in the appropriate variant?

@hashmap
Copy link
Contributor Author

hashmap commented Apr 2, 2019

@JeremyRubin I had the same feelings and tried different approaches, but haven't find anything more reasonable than just use chain::Error. My main rationale that the code must be candid.

We deal with ChainAdapter, so we should accept the fact that we have a dependency on chain crate. The methods should return chain::Error for the same reason. Actually I changed the trait first and then worked with implementations, so it was a design decision.

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.

@hashmap hashmap modified the milestones: 1.0.3, 1.1.0 Apr 2, 2019
@garyyu
Copy link
Contributor

garyyu commented Apr 4, 2019

@hashmap

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.

what's this it? ^
#2542 or this PR?

@hashmap
Copy link
Contributor Author

hashmap commented Apr 4, 2019

@garyyu the idea to have a designated error crate I proposed as an option in #2542

Copy link
Contributor

@ignopeverell ignopeverell left a 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.

@hashmap hashmap merged commit 94732b0 into mimblewimble:master Apr 8, 2019
@hashmap hashmap deleted the chain-adapter-result branch April 8, 2019 20:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants