debugging support #74

Merged

jvanasco merged 1 commit from master into master

2012-04-08 17:29:06 -07:00

jvanasco commented

2012-04-08 15:51:08 -07:00

(Migrated from github.com)

i added some support for debugging issues with twython

i'm not sure how/where the tests are , i would have written some to your harness if i did.

full details below, but...

1- tests the API response to ensure it's valid, throws a TwythonError with details if needed.
2- stashes the info from the last api request -- so you can inspect and try to figure out what happened.
3- added benefit - you have access to the headers that described ratelimiting status

added twitter's http status codes to twitter_endpoints.py ( dict index on status code, value is a tuple of name + description )
created an internal stash called '_last_call' that stores details of the last api call ( the call, response data, headers, url, etc )
better error handling for api issues:
- raises an error when the status code is not 200 or 304
- raises TwythonAPILimit when a 420 rate limit code is returned
- raises a TwythonError on other issues, setting the correct status code and using messages that are from the twitter API
wraps a successful read in a try/except block. there's an error i haven't been able to reproduce where invalid content can get in there, it would be nice to catch it and write a handler for it. ( the previous functions were all introducted to allow this to be debugged )
added a 'get_lastfunction_header' method. if the API has not been called yet , raises a TwythonError. otherwise it attempts to return the header value twitter last sent. useful for x-ratelimit-limit , x-ratelimit-remaining , x-ratelimit-class , x-ratelimit-reset

i added some support for debugging issues with twython i'm not sure how/where the tests are , i would have written some to your harness if i did. full details below, but... 1- tests the API response to ensure it's valid, throws a TwythonError with details if needed. 2- stashes the info from the last api request -- so you can inspect and try to figure out what happened. 3- added benefit - you have access to the headers that described ratelimiting status --- - added twitter's http status codes to twitter_endpoints.py ( dict index on status code, value is a tuple of name + description ) - created an internal stash called '_last_call' that stores details of the last api call ( the call, response data, headers, url, etc ) - better error handling for api issues: - \- raises an error when the status code is not 200 or 304 - \- raises TwythonAPILimit when a 420 rate limit code is returned - \- raises a TwythonError on other issues, setting the correct status code and using messages that are from the twitter API - wraps a successful read in a try/except block. there's an error i haven't been able to reproduce where invalid content can get in there, it would be nice to catch it and write a handler for it. ( the previous functions were all introducted to allow this to be debugged ) - added a 'get_lastfunction_header' method. if the API has not been called yet , raises a TwythonError. otherwise it attempts to return the header value twitter last sent. useful for x-ratelimit-limit , x-ratelimit-remaining , x-ratelimit-class , x-ratelimit-reset

ryanmcgrath commented

2012-04-08 17:28:47 -07:00

(Migrated from github.com)

I like this. We shall merge, yes yes.

Kudos to you; there are currently no tests because... well, I find tests quite boring development wise. Not to say I can't do them, but when I initially released the library I decided to get it out first.

...then they just never showed up, primarily due to a lack of time. I figure if people want/need them they'll put them in, it's open source for a reason.

I like this. We shall merge, yes yes. Kudos to you; there are currently no tests because... well, I find tests quite boring development wise. Not to say I can't do them, but when I initially released the library I decided to get it out first. ...then they just never showed up, primarily due to a lack of time. I figure if people want/need them they'll put them in, it's open source for a reason.

jvanasco commented

2012-04-08 18:09:11 -07:00

(Migrated from github.com)

rad. i'm fine with no tests. i like to focus on getting-shit-done for personal projects too.