meilisearch/meilisearch-rust

Ensure the error handling are following the best practice

Opened this issue · 1 comments

brunoocasali commented

⚠️ This issue is generated, it means the examples and the namings do not necessarily correspond to the language of this repository.
Also, if you are a maintainer, please add any clarification and instructions about this issue.

Sorry if this is already wholly/partially implemented. Feel free to let me know about the state of this issue in the repo.

Related to meilisearch/integration-guides#267

⚠️ For more information check meilisearch/integration-guides#267

Ensure this SDK follows the following guidelines:

  • All the errors > 400 without message should be sent as MeilisearchCommunicationError
  • Know errors like index is not found, or mistakes in the request like not-allowed params should be sent as MeilisearchApiError
  • Any other error should be a MeilisearchError

Essentially all the error should extend from MeilisearchError, the consumers should have a way to catch all the errors.
Let us know if this is not clear, or you have better idea!

TODO:

  • Create a base error called MeilisearchError which will extend the standard error if it does not exist (when the language supports)
  • Make all the other errors extend this error.
  • Move all errors without message to MeilisearchCommunicationError since it is not a Meilisearch error anyway.
irevoire commented

[ ] Create a base error called MeilisearchError which will extend the standard error if it does not exist (when the language supports)
[ ] Make all the other errors extend this error.

Hey, I’m just adding a little clarification on these two lines. In rust we don’t extend things since we're not using inheritance but composition.
However, for error handling, we usually don’t use oop and use our algebraic data type, the enums.
Since we're already using thiserror the pattern we should follow is:

#[derive(thiserror::Error)]
pub enum MeilisearchError {
  MeilisearchCommunicationError,
  MeilisearchApiError(#[from] ...), // here you should create a type that receives the meilisearch errors
  MeilisearchError(Box<dyn Error>), // shove everything else in here if it implements the error trait.
}

Or sometimes, instead of having a generic Box<dyn Error> that can break easily and is hard to pattern match, people return the error received. That's what we're currently doing, I believe.
This let our final user pattern match on the error we returned and react accordingly. (i.e.: If you see a serde error saying it can't deserialize your type, then you know it's an internal error on your side and not on meilisearch because it just uses serde).

  • 🚀1