Skip to content

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

Closed
w- opened this issue May 20, 2017 · 14 comments
Labels
status: help wanted requesting help from the community type: community enhancement feature request not on Twilio's roadmap

Comments

@w-
Copy link

w- commented May 20, 2017

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

  1. make an api call that returns anything other than HTTP2xx
  2. attempt to handle error raised without importing urllib and without doing a catch all.

Technical details:

  • python-http-client Version: master (latest commit: [commit number])
  • Python Version: all
@thinkingserious
Copy link
Contributor

Please see sendgrid/sendgrid-python#316

Thanks!

@w-
Copy link
Author

w- commented May 22, 2017

@thinkingserious don't think this shojuld be closed. please see sendgrid/sendgrid-python#315 (comment)

@thinkingserious
Copy link
Contributor

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!

@w-
Copy link
Author

w- commented May 22, 2017

@thinkingserious can you help provide a direct link?
I went through the commit list but nothing obvious jumped out

thanks

@w-
Copy link
Author

w- commented May 22, 2017

i see. i thought you were talking about latest commit to this library.
I think both of you guys may be missing the point i'm attempting to communicate.

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
sendgrid/sendgrid-python#316

@thinkingserious
Copy link
Contributor

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

@w-
Copy link
Author

w- commented May 23, 2017

As i mentioned in other comments, because of the way python-http-client is implemented i'm unsure.

maybe here?
https://github.com/sendgrid/python-http-client/blob/master/python_http_client/client.py#L138

so we would define a HttpClientError similar to what i define here
sendgrid/sendgrid-python#316 (comment)

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.
also, in tracebacks we don't see it point to underlying code in urllib (why would a consumer ever care?)

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.

@w-
Copy link
Author

w- commented May 23, 2017

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.
so maybe instead of throwing an error, python-http-client, just returns an HTTP response?

not sure about that either.

@thinkingserious
Copy link
Contributor

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.

How about we raise something like ConnectionError, Timeout, HTTPError and TooManyRedirects similar to requests? (But, I think we can include Timeout in ConnectionError for simplicity)

@dibyadas
Copy link
Contributor

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.
So then, the sendgrid-python should be aware of only python-http-client and not urllib.

@thinkingserious
Copy link
Contributor

@dibyadas,

Do you want to give it a try with a PR? Or would you like me to give it a shot?

@thinkingserious thinkingserious added status: help wanted requesting help from the community type: community enhancement feature request not on Twilio's roadmap and removed status: duplicate duplicate issue labels May 23, 2017
@dibyadas
Copy link
Contributor

@thinkingserious I would love to work on this! I can give it a try and you can guide me and suggest changes and improvements. 😄
What do you say?

@thinkingserious
Copy link
Contributor

Awesome, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: help wanted requesting help from the community type: community enhancement feature request not on Twilio's roadmap
Projects
None yet
Development

No branches or pull requests

3 participants