Reviewing of error handling about integration-guides

[sanders41]

I have a general question for some additional context. Have people reported issues with the current errors? I haven't seen any. I'm trying to think of a time when this would be an issue. Taking the 404 as an example, in this case the error won't be a specific Meilisearch error, but it will be clear what the issue is since the underlying library handling the http requests will show the 404.

I'm just wondering if making a change will add a lot of extra maintenance for not much benefit.

[alallema]

Hi @sanders41,
That's an excellent question, indeed. When we first implemented the versionErrorHintMessage method, we realized that you weren't all aligned on the definition of errors. Moreover, some names like wait_for_task return a MeilisearchTimeoutError are not necessarily appropriate.
In addition, we try to remain vigilant and up to date regarding the errors returned in SDKs, as it can save a lot of situations to have clear and concise errors.
But this is more of a reminder and reflection on the subject for now.

[bidoubiwa]

I think this option is the best:

Transfer errors > 400 and without message to CommunicationError (I am not in favor of this solution)

About MeilisearchError I know @brunoocasali would like that all other errors inherit from this error (at least in the languages where it is possible).

For the MeilisearchTimeoutError, I would like to rename it MeilisearchWaitForTaskTimeOut or something that does not imply the Meilisearch server timed out.

[brunoocasali]

I've opened issues in each repository, and I will close this issue now.

I believe this change could be beneficial for the consumers and for the maintainers, since it is going to ensure a concise public API regarding the errors and will make things easier when you try to catch errors in the test suite.