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

The inconsistency of init APIs #221

Open
zhangwei983 opened this issue Jun 4, 2024 · 4 comments
Open

The inconsistency of init APIs #221

zhangwei983 opened this issue Jun 4, 2024 · 4 comments

Comments

@zhangwei983
Copy link

The init APIs of StableBTreeMap and StableVec returns inconsistent results:

  1. StableBTreeMap::init returns StableBTreeMap
  2. StableVec::init returns Result<StableVec, InitError>
    Actually MinHeap also returns a Result.

Looks like StableVec uses the safe_write method which returns a Result.

Should StableBTreeMap::init do the same thing and return a Result?

@dsarlis
Copy link
Member

dsarlis commented Jun 6, 2024

Is there a specific concern that you have or is it mostly about consistency/uniformity of the APIs?

@ielashi
Copy link
Contributor

ielashi commented Jun 7, 2024

The (not very good reason) this inconsistency exists is because these structures were written by different authors. The current thinking is to update them to all not return a Result, since the errors returned aren't really recoverable. Would be curious to hear your opinions on this issue.

@zhangwei983
Copy link
Author

Is there a specific concern that you have or is it mostly about consistency/uniformity of the APIs?

It's not a usage issue. For me, it's just a convention or a habit to make the high-level APIs consistent. :)

@zhangwei983
Copy link
Author

The (not very good reason) this inconsistency exists is because these structures were written by different authors. The current thinking is to update them to all not return a Result, since the errors returned aren't really recoverable. Would be curious to hear your opinions on this issue.

If it's not recoverable or doesn't expect the users to handle the error, then not returning a Result is a better option IMO.

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

No branches or pull requests

3 participants