Skip to content
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

OAuth1Binding.prototype._call makes response.content inaccessible when an error occurs #552

Closed
timhaines opened this issue Dec 15, 2012 · 5 comments

Comments

@timhaines
Copy link
Contributor

I'm using OAuth1Binding to talk to the TwitterAPI.

The TwitterAPI will return an error code in the response.statusCode, and will also provide more information in the response.content / response.data.

Some statusCode's can represent multiple different types of errors, which are disclosed in the statusCode. Example: {"message":"Rate limit exceeded","code":88}

Currently OAuth1Binding.prototype._call throws an error based on the statusCode only, making the details of the error inaccessible.

OAuth1Binding.prototype._call should perhaps be updated to not throw an error but instead return the failed request to the caller for interpretation.

@avital
Copy link
Contributor

avital commented Dec 15, 2012

@timhaines Can we instead continue to throw an error but find some way to add on the additional relevant information?

@timhaines
Copy link
Contributor Author

@avital Thanks for the guidance. I've just seen extra properties can be added to the error object before throwing it (I'm a js newb). Would this kind of approach be appropriate? https://github.com/jdub/node-twitter/blob/master/lib/twitter.js#L95-L99

@avital
Copy link
Contributor

avital commented Dec 15, 2012

Yes, something like that. I believe response.error is already an object at that point so you should just be able to add properties on that before returning it. (I'm looking at oauth1_binding.js:128)

@avital
Copy link
Contributor

avital commented Dec 27, 2012

Is this now resolved on devel?

@timhaines
Copy link
Contributor Author

Yes. Resolved when you merged #574

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants