Twitter::Error.errors lists descendants recursively

[pengwynn]

While stealing borrowing the improved client/server exception handling approach for Octokit.rb, I noticed that Twitter::Error.errors throws an exception:

>> Twitter::Error.errors
NameError: uninitialized constant Twitter::Error::ClientError::HTTP_STATUS_CODE
        from /Users/wynn/.coral/repos/twitter@sferik/lib/twitter/error.rb:20:in `block in errors'
        from /Users/wynn/.coral/repos/twitter@sferik/lib/twitter/error.rb:19:in `each'
...

This change makes that method a bit more defensive and allows child error types to be listed recursively.

[coveralls]

Changes Unknown when pulling 9d904a1 on list-recursive-errors into * on master*.

[sferik]

This introduces a bug with 403 errors, which should have the class Twitter::Error::Forbidden. After this patch, they will have the class Twitter::Error::AlreadyPosted, which subclasses Twitter::Error::Forbidden, so it has the same HTTP_STATUS_CODE constant.

Since client errors and server errors are not handled differently anymore, I may fix this by removing the Twitter::Error::ClientError and Twitter::Error::ServerError classes and have all error inherit directly from Twitter::Error, which would also solve this.

I’ve added this to the Version 5 milestone, so it will be resolved one way or the other before the next release.

I’ll also add a spec that expects Twitter::Errors.errors[403] to return Twitter::Error::Forbidden, since this is currently an unspecified expectation.

[pengwynn]

👍

I've since run into that in Octokit, too (with GitHub's 403 responses). I'm looking at the best way to handle that, perhaps with a .match? on each error type method that evaluates status and response body, picking the deepest child that returns true for that method.