-
Notifications
You must be signed in to change notification settings - Fork 19
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
Relocate errors #154
Comments
With #81 and other changes lined up for Tekore 2.0, we could consider setting up an exception hierarchy. I'm not quite sure if it's better to create all errors through a base class, and the same for warnings. |
Maybe a base class is not the way to go. Warnings should inherit from user warnings, as they do already. Custom exceptions are only raised on bad HTTP codes and in id conversions. I think conversion is ok, but After we change from using Requests to HTTPX, the error base class should be either the error of HTTPX or a class of our own inheriting from that. Or we could have the HTTPError equivalent imported at the top level, from which users could use it directly without knowing it's a part of HTTPX. |
We could also provide bases for client and server errors separately. |
HTTP errors are now raised in
tekore.client.decor.error
, which is quite lengthy if you're trying to import it for error handling. We should relocate them totekore.error
and maybe even consider importing them to the top level.The text was updated successfully, but these errors were encountered: