-
Notifications
You must be signed in to change notification settings - Fork 986
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
Add new error classes #841
Conversation
…-class (e.g. `ClientError`) was previously accessible either through the `Faraday` module (e.g. `Faraday::ClientError`) or through the `Faraday::Error` class (e.g. `Faraday::Error::ClientError`). The latter is no longer available and the former should be used instead, so check your `rescue`s. * Introduces a new `Faraday::ServerError` (5xx status codes) alongside the existing `Faraday::ClientError` (4xx status codes). Please note `Faraday::ClientError` was previously used for both. * Introduces new Errors that describe the most common REST status codes: * Faraday::BadRequestError (400) * Faraday::UnauthorizedError (401) * Faraday::ForbiddenError (403) * Faraday::ProxyAuthError (407). Please note this raised a `Faraday::ConnectionFailed` before. * Faraday::UnprocessableEntityError (422)
@olleolleolle you're welcome to have a review 👍 ! |
As of lostisland/faraday#841, we've changed the exceptions namespace. This change needs to be reflected on exceptions raised by this adapter. This change is required in order to support Faraday 1.0, and should be fully backwards-compatible with older versions of Faraday.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are some “looked through the code” comments.
Change is good!
@@ -1,5 +1,6 @@ | |||
RSpec.describe Faraday::Adapter::Typhoeus do | |||
features :body_on_get, :parallel | |||
|
|||
it_behaves_like 'an adapter' | |||
# Commenting until Typhoeus is updated to support v1.0 | |||
# it_behaves_like 'an adapter' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would an xit
work?
expect { conn.get('ok') }.not_to raise_error | ||
end | ||
|
||
it 'raise Faraday::Error::ResourceNotFound for 404 responses' do | ||
expect { conn.get('not-found') }.to raise_error(Faraday::Error::ResourceNotFound) do |ex| | ||
it 'raise Faraday::ResourceNotFound for 400 responses' do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The description could use the “raises” tense of that verb (throughout these cases). It was the wrong form before your changes, too.
@olleolleolle Thanks for pointing out both! |
Description
Faraday::Error
. A sub-class (e.g.ClientError
) was previously accessible either through theFaraday
module (e.g.Faraday::ClientError
) or through theFaraday::Error
class (e.g.Faraday::Error::ClientError
).The latter is no longer available and the former should be used instead, so check your
rescue
s.Faraday::ServerError
(5xx status codes) alongside the existingFaraday::ClientError
(4xx status codes).Please note
Faraday::ClientError
was previously used for both.Faraday::ConnectionFailed
before.Todos
List any remaining work that needs to be done, i.e:
Additional Notes
Replaces #735