Handling error responses in client

49 views
Skip to first unread message

Beth

unread,
Apr 29, 2014, 6:58:02 PM4/29/14
to roar...@googlegroups.com
I cant see any immediately obvious way to detect and handle non-success responses when using the Faraday client. Anyone have any examples or docs?

Cheers.

Nick Sutterer

unread,
Apr 29, 2014, 6:59:41 PM4/29/14
to roar...@googlegroups.com
Give an example how handling errors would look like and we can add it. I haven't used the Faraday adapter myself.


On Wed, Apr 30, 2014 at 8:58 AM, Beth <bet...@gmail.com> wrote:
I cant see any immediately obvious way to detect and handle non-success responses when using the Faraday client. Anyone have any examples or docs?

Cheers.

--
You received this message because you are subscribed to the Google Groups "Roar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to roar-talk+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Felix Wolfsteller

unread,
Sep 4, 2014, 12:32:21 PM9/4/14
to roar...@googlegroups.com
I would like to see this behaviour, too (although in the Net::Http adapter, as I also do not user faraday).

I see multiple ways to implement the behaviour, of wich i will outline some and which are possible to combine.

1. Like Mechanize, throw an Exception if the response is not .kind_of? Net::HTTPSuccess. And (also like Mechanize (http://rubydoc.info/gems/mechanize/Mechanize/HTTP/Agent#allowed_error_codes-instance_method), allow that certain error codes would be ignored. Code would go into lib/roar/representer/feature/http_verbs.rb#handle_response, I guess.
This, for my understanding changes the API usage, it is an incompatible change.

2. Have a post! (and the usual post) method, and respective other http-verbs-BANG methods, that return the response (instead of the representer) but update the represented object, if possible. Handling errors is then left to the caller. The post-method would return a new representer. Again, incompatible change.

3. Have the behaviour controlled by an additional parameter to #post, #get etc (raise_on_error: true, ignore_error_codes: [407]).

4. Implement new methods like post_response that acts similar to the "post!" outlined above.

I somewhat favor the post! - way. I will create an github issue and link to a repository, where I made minimal changes to the sinatra example_server to have a base for discussion.

Have fun,
felix
  1. Like e.g. Mechanize, throw an Exception if the response is not  response.kind_of? Net::HTTPSuccess. Like

Felix Wolfsteller

unread,
Sep 4, 2014, 2:10:12 PM9/4/14
to roar...@googlegroups.com
It's github issue https://github.com/apotonick/roar/issues/106 then.
Enjoy,
felix
Reply all
Reply to author
Forward
0 new messages