client.get_feed_submission_result id
# => Excon::Errors::NotFound: Expected(200) <=> Actual(404 Not Found)
If you don't already have a notion of what this means, the workaround is to rescue and peek into response:
begin
client.get_feed_submission_result id
rescue Exception => ex
puts ex.response.parse
# => {"Type"=>"Sender", "Code"=>"FeedProcessingResultNotReady", "Message"=>"Feed Submission Result is not ready for Feed 191837016796", "Detail"=>nil}
end
Instead, we could perhaps throw an error that inherits from Excon::Errors::NotFound, sets class name to the value of Code—FeedProcessingResultNotReady in this case—and set the error message to the value of Message. Inheriting from the original error should make this largely backwards-compatible, assuming people rescue Excon error types to handle specific cases (throttling, etc.).
Current errors are not expressive:
If you don't already have a notion of what this means, the workaround is to rescue and peek into response:
Instead, we could perhaps throw an error that inherits from
Excon::Errors::NotFound, sets class name to the value ofCode—FeedProcessingResultNotReadyin this case—and set the error message to the value ofMessage. Inheriting from the original error should make this largely backwards-compatible, assuming people rescue Excon error types to handle specific cases (throttling, etc.).