Add `code` attribute to error classes

[saikambaiyyagari]

Hi @sferik,

It's not an issue related to code or feature requests. But I just wanted to check with you on your plans to release the next patch/minor version.

Thanks

[sferik]

I’ll probably release version 0.11.0 sometime next week.

In the mean time, you can specify a git source in your Gemfile like so:

gem "x", :git => "https://github.com/sferik/x-ruby.git"

I’m curious which yet-to-be-released specific bug fix or feature that that you were hoping to use?

[sferik]

By the way, I noticed you work at Zendesk. Do you think they’d have any interest in sponsoring my work on this gem? For as little as $1/month, Zendesk’s logo could appear here and I would prioritize your bug reports and feature requests.

[saikambaiyyagari]

Thanks, @sferik, for the reply. Yes, we are specifying a git source in our Gemfile, pointing it to the recent commit e.g., gem 'x', 'git': 'https://github.com/sferik/x-ruby.git', 'ref': '5b8c655'

We were interested in the error-handling changes - https://github.com/sferik/x-ruby/commit/853d39c60d55d65002a66df151d543be92bb35fc the addition of new client and server errors. It keeps it consistent with the previous Twitter-ruby gem. Thanks for all the effort.

We have some questions on the error handling implementation-

a. In the previous twitter-ruby, the error object contains the actual message from Twitter. For e.g, When Twitter responds with unauthorized error, the error object will contain the actual error message from Twitter ->

begin
  old_api_client.verify_credentials
rescue ::Twitter::Error => e
  e.inspect
end

will return -> #<Twitter::Error::Unauthorized: Could not authenticate you.>

But in the new x-ruby implementation - we see only the error code.

begin
  x_api_client.get('account/verify_credentials.json')
rescue ::X::Error => e
  e.inspect
end

will return -> #<X::AuthenticationError: 401 Unauthorized>

b. Also, in the previous twitter-ruby gem, the client and server error classes has code attribute - which is very useful for us to keep action/logic based on the specific code.

Question: Can we also expect these helpful error-handling code paths to be introduced in x-ruby? Please, let me know your thoughts.

[saikambaiyyagari]

By the way, I noticed you work at Zendesk. Do you think they’d have any interest in sponsoring my work on this gem? For as little as $1/month, Zendesk’s logo could appear here and I would prioritize your bug reports and feature requests.

Sure. I will check and get back to you. Thanks for all the good work 💪🏾

[sferik]

@saikambaiyyagari I just came here to close this issue, since I just release 0.11.0, but then I saw your latest feature requests.

In the latest version, errors will bubble up the message from Twitter, which should help with debugging. I’d also be willing to add a code attribute to descendants of the X::Error class. This is a good example of the type of feature request I would prioritize if Zendesk decided to sponsor this project. Thank you for asking about that!

Instead of closing this issue, I will rename it and keep it open until that feature is added.

In the mean time, you could use the X::ResponseParser::ERROR_CLASSES hash to map from codes to errors (if you need to map from errors to codes, you could invert it).

[sferik]

Released in 0.12.0. Please note that the X::ResponseParser::ERROR_CLASSES constant was renamed to ERROR_MAP, so if you were using that, you’ll need to update your code. That said, you shouldn’t need to use it now that the HTTPError#code attribute exists.