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.

Sign up for GitHub

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

Jump to bottom

Raise exception on nil status #1042

Merged
merged 2 commits into from Oct 15, 2019
Merged

Raise exception on nil status #1042

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6adf096
Raise exception on nil status
michaelherold Sep 27, 2019
2c81ed6
Pass the exception correctly
jonnyom Oct 4, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 8 additions & 0 deletions lib/faraday/error.rb
View file
Open in desktop
Expand Up @@ -83,6 +83,14 @@ def initialize(exc = 'timeout', response = nil)
end
end

# Raised by Faraday::Response::RaiseError in case of a nil status in response.
class NilStatusError < ServerError
def initialize(_exc, response: nil)
message = 'http status could not be derived from the server response'
super(message, response)
end
end

# A unified error for failed connections.
class ConnectionFailed < Error
end
Expand Down
2 changes: 2 additions & 0 deletions lib/faraday/response/raise_error.rb
View file
Open in desktop
Expand Up @@ -28,6 +28,8 @@ def on_complete(env)
raise Faraday::ConflictError, response_values(env)
when 422
raise Faraday::UnprocessableEntityError, response_values(env)
when nil
raise Faraday::NilStatusError, response: response_values(env)
Comment on lines +31 to +32
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I'd rather have the nil check at the bottom, since it's the least likely to occur than any numerical status. Pretty minor issue, so I'm not sure if it's worth the effort :)
  2. I like passing response as a named variable, rather than positional. I've added a note to the v2 wishlist (Faraday Wishlist #953) to make this consistent with the other error types.

when ClientErrorStatuses
raise Faraday::ClientError, response_values(env)
when ServerErrorStatuses
Expand Down
7 changes: 7 additions & 0 deletions spec/faraday/response/raise_error_spec.rb
View file
Open in desktop
Expand Up @@ -14,6 +14,7 @@
stub.get('conflict') { [409, { 'X-Reason' => 'because' }, 'keep looking'] }
stub.get('unprocessable-entity') { [422, { 'X-Reason' => 'because' }, 'keep looking'] }
stub.get('4xx') { [499, { 'X-Reason' => 'because' }, 'keep looking'] }
stub.get('nil-status') { [nil, { 'X-Reason' => 'bailout' }, 'fail'] }
stub.get('server-error') { [500, { 'X-Error' => 'bailout' }, 'fail'] }
end
end
Expand Down Expand Up @@ -72,6 +73,12 @@
end
end

it 'raises Faraday::NilStatusError for nil status in response' do
expect { conn.get('nil-status') }.to raise_error(Faraday::NilStatusError) do |ex|
expect(ex.message).to eq('http status could not be derived from the server response')
end
end

it 'raises Faraday::ClientError for other 4xx responses' do
expect { conn.get('4xx') }.to raise_error(Faraday::ClientError) do |ex|
expect(ex.message).to eq('the server responded with status 499')
Expand Down