-
Notifications
You must be signed in to change notification settings - Fork 102
python-http-client should define it's own error class which can be imported by consuming libraries #16
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
Comments
Please see sendgrid/sendgrid-python#316 Thanks! |
@thinkingserious don't think this shojuld be closed. please see sendgrid/sendgrid-python#315 (comment) |
Hi @w-, It looks like this functionality was just added in the latest commit. Do you mind taking a look? I have not yet fully reviewed the PR, but this functionality will be included before we merge it. Thanks! |
@thinkingserious can you help provide a direct link? thanks |
i see. i thought you were talking about latest commit to this library. I believe that there needs to be a better implementation around how errors are raised from the underlying python-http-client library to the sendgrid-python library and ultimately to the consuming code. I've left some additional comments |
Hi @w-, Thank you for the continued feedback. Could you provide an example of where you would make changes in this repo? That would probably help clarify. Thanks in advance :) With Best Regards, Elmer |
As i mentioned in other comments, because of the way python-http-client is implemented i'm unsure. maybe here? so we would define a HttpClientError similar to what i define here and we would wrap that return statement like so: try:
return opener.open(request)
except urllib.HttpError as err:
raise HttpClientError(err.url, err.code, err.hdrs, err.read()) now a consuming library only needs to be aware of HttpClientError which it can import from python-http-client. The reason we want a structured exception instead of a generic one is so we can add logic to our exception handling at the sendgrid-python level. a prime case is differentiating between regular API Errors and Rate Limiting errors. Or permission vs bad inputs. etc. |
as an aside, i'm also unsure that throwing an exception on http error is the way to go. I think it can also be considered normal to receive a non success HTTP response and let the consumer decide how they want to handle it. not sure about that either. |
How about we raise something like |
I second @w- on this. If we are having our own library, we might as well define our own exceptions. This way, anyone who uses this library is not bothered about any underlying implementations. |
Do you want to give it a try with a PR? Or would you like me to give it a shot? |
@thinkingserious I would love to work on this! I can give it a try and you can guide me and suggest changes and improvements. 😄 |
Awesome, thanks! |
Issue Summary
If the response is not success (i.e not HTTP2xx) the library throws a urllib HTTPError.
For clients consuming this library, they now need to know that it was implemented in urllib, import that module into their application and handle the error.
Ideally, a consuming application only needs to know about python-http-client and not how urllib was implemented in order to handle common place http errors.
Steps to Reproduce
Technical details:
The text was updated successfully, but these errors were encountered: