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

Add error type for combine keys + test and doc #304

Merged

Conversation

Tibo-lg
Copy link
Contributor

@Tibo-lg Tibo-lg commented Jun 10, 2021

Trying to address the issues raised here:

  • Add error type for combine_keys
  • Add test with empty slice for combine_keys
  • Document empty slice error condition for combine_keys

Deleted the TweakCheckFailed at the same time since it's not used but let me know if you'd prefer to have that in a separate commit/PR.

@real-or-random I was not sure if you wanted to change something in the fuzz_dummy module and I'm not so familiar with what it does so let me know if it does need a change.

@apoelstra
Copy link
Member

This is a breaking change - let me check if we can push out a minor release before this.

@apoelstra
Copy link
Member

Yes. Will need to wait for #305

@Tibo-lg
Copy link
Contributor Author

Tibo-lg commented Jun 10, 2021

This is a breaking change

Is it because of deleting TweakCheckFailed? I don't think there is any hurry to merge this anyway but I can also just restore it.

@apoelstra
Copy link
Member

Yes, though also because we added the other variant that replaces it.

@@ -395,11 +395,15 @@ impl PublicKey {

/// Adds the keys in the provided slice together, returning the sum. Returns
/// an error if the result would be the point at infinity, i.e. we are adding
/// a point to its own negation
/// a point to its own negation, or if the provided slice has no element in it.
pub fn combine_keys(keys: &[&PublicKey]) -> Result<PublicKey, Error> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure whether it is a good practice to return general error type when in fact only a single error subtype may be caused by the function. I think replacing Result<_, Error> on Result<_, InvalidPublicKeySum> will do a better job (the caller, if needed, may convert the error into general Error crate type).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't speak for what is good practice or not, but looking at the rest of the code I feel like doing what you propose would be inconsistent with it, so if that's the way we want to go it might be better to make the change everywhere at once.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I also have seen that all functions in the lib used to return the single error type, which is a thing is not a good API, but this will certainly require distinct PR

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If all of our functions returned distinct error types it would be an extremely unergonomic API, requring downstream users to wrap all of our individual types and implementing From on them to convert to their own error types.

dr-orlovsky
dr-orlovsky previously approved these changes Jun 21, 2021
apoelstra
apoelstra previously approved these changes Jul 9, 2021
Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack e2e1abf

sgeisler
sgeisler previously approved these changes Jul 15, 2021
Copy link
Contributor

@sgeisler sgeisler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK e2e1abf

src/key.rs Outdated Show resolved Hide resolved
@elichai
Copy link
Member

elichai commented Sep 2, 2021

utACK 674cc79

Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 674cc79

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

Successfully merging this pull request may close these issues.

5 participants