[katello-devel] Introducing ApiError in the ApiController

[Lukas Zapletal]

On 07/28/2011 02:39 PM, Dmitri Dolguikh wrote:
> i disagree: i think in the case of rest api, we should rely more on http
> status codes to provide more meaningful exceptions, otherwise the client
> is forced to parse our textual error messages (which is less reliable,
> language-locale dependent, etc). I'd say we should use 500 for all
> internal issues (such as db is down, out of memory, etc), i.e. issues
> where user is not at fault, and cannot do anything to correct the issue.
> If corrective action by the user is possible, we should use an
> appropriate http status code.

Yeah. I slightly reworked it. I think the code is self-describing:

module HttpErrors

   class WrappedError < StandardError
     attr_reader :original

     def initialize(msg, original=$!)
       super(msg)
       @original = original
     end
   end

   # application general errors
   class AppError < WrappedError; end
   class ApiError < AppError; end

   # specific errors
   class NotFound < WrappedError; end
   class BadRequest < WrappedError; end

end

raise HttpErrors::ApiError, _("Manifest import failed")

raise HttpErrors::NotFound, _("Couldn't find xyz")

log example:

*** ERROR: user-friendly message goes here (500) ***
REQUEST URL: /api/users
HttpErrors::ApiError: user-friendly message goes here
/data/work/CloudForms/katello/src/app/controllers/api/api_controller.rb:45:in 
`current_user'
/data/work/CloudForms/katello/src/lib/util/threadsession.rb:75:in 
`thread_locals'
/home/lzap/.rvm/gems/ruby-1.8.7-p334 at katello/gems/activesupport-3.0.5/lib/active_support/callbacks.rb:219:in 
`_  ...........


-- 
Later,

  Lukas Zapletal | E32E400A
  RHN Satellite Engineering
  Red Hat Czech s.r.o. Brno