Skip to content

Error handling with callbacks is counterintuituve #72

benilovj opened this Issue Feb 21, 2013 · 0 comments

2 participants


This is more a design issue rather than a specific bug, but I personally find having to handle API error cases with callbacks instead of exceptions bewildering (so much so that we've created our own wrapper for the zendesk_api gem). Here's an example from #71:

class SearchError < Exception; end

client.insert_callback do |env|
  if env[:status] == 500 && env[:url].request_uri =~ %r{/search}
    # Must not be a Faraday::Error::ClientError, but could be any standard ruby error
    raise SearchError

This pattern forces each app that uses the zendesk_api gem to know intimate details of the Zendesk REST API (the error conditions for which aren't documented anywhere, to my knowledge). While I understand the perils of abstracting away the distributed nature of the API access completely, this feels like a very leaky abstraction - isn't the whole point of a wrapper to hide precisely these kinds of details from the application developer?

My proposed solution would be to raise (and document!) pre-defined exceptions for error cases known in advance (e.g. authentication error, validation errors, transient unavailability errors) by default, or alternatively follow the Rails method semantics and have methods ending with ! raise exceptions and methods without ! returning false or nil.

@steved steved closed this Jun 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.