Benutzerdefinierte Fehlerbehandlung mit Rails 4.0

Ich baue eine Ruby on Rails-API mit Ruby 2.0 und Rails 4.0. Meine App ist fast ausschließlich eine JSON-API. Wenn also ein Fehler auftritt (500, 404), möchte ich diesen Fehler erfassen und eine gut formatierte JSON-Fehlermeldung zurückgeben.

ich habe es versuchtdiese und auch:

rescue_from ActionController::RoutingError, :with => :error_render_method

def error_render_method
  puts "HANDLING ERROR"
  render :json => { :errors => "Method not found." }, :status => :not_found
  true
end

In meinem ApplicationController.

Keiner von beiden macht den Trick (die Ausnahmen werden überhaupt nicht erfasst). Mein Googeln zeigt, dass sich zwischen 3.1, 3.2 einiges geändert hat, und ich kann keine gute Dokumentation dazu in Rails 4.0 finden.

Weiß jemand Bescheid?

Bearbeiten Hier ist die Stapelverfolgung, wenn ich zu einer 404-Seite gehe:

Started GET "/testing" for 127.0.0.1 at 2013-08-21 09:50:42 -0400

ActionController::RoutingError (No route matches [GET] "/testing"):
actionpack (4.0.0) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
actionpack (4.0.0) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
railties (4.0.0) lib/rails/rack/logger.rb:38:in `call_app'
railties (4.0.0) lib/rails/rack/logger.rb:21:in `block in call'
activesupport (4.0.0) lib/active_support/tagged_logging.rb:67:in `block in tagged'
activesupport (4.0.0) lib/active_support/tagged_logging.rb:25:in `tagged'
activesupport (4.0.0) lib/active_support/tagged_logging.rb:67:in `tagged'
railties (4.0.0) lib/rails/rack/logger.rb:21:in `call'
actionpack (4.0.0) lib/action_dispatch/middleware/request_id.rb:21:in `call'
rack (1.5.2) lib/rack/methodoverride.rb:21:in `call'
rack (1.5.2) lib/rack/runtime.rb:17:in `call'
activesupport (4.0.0) lib/active_support/cache/strategy/local_cache.rb:83:in `call'
rack (1.5.2) lib/rack/lock.rb:17:in `call'
actionpack (4.0.0) lib/action_dispatch/middleware/static.rb:64:in `call'
railties (4.0.0) lib/rails/engine.rb:511:in `call'
railties (4.0.0) lib/rails/application.rb:97:in `call'
rack (1.5.2) lib/rack/lock.rb:17:in `call'
rack (1.5.2) lib/rack/content_length.rb:14:in `call'
rack (1.5.2) lib/rack/handler/webrick.rb:60:in `service'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/webrick/httpserver.rb:138:in `service'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/webrick/httpserver.rb:94:in `run'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/webrick/server.rb:295:in `block in start_thread'


Rendered /Library/Ruby/Gems/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/templates/rescues/_trace.erb (1.0ms)
Rendered /Library/Ruby/Gems/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/templates/routes/_route.html.erb (2.9ms)
Rendered /Library/Ruby/Gems/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/templates/routes/_route.html.erb (0.9ms)
Rendered /Library/Ruby/Gems/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/templates/routes/_table.html.erb (1.1ms)
Rendered /Library/Ruby/Gems/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (38.3ms)

Ich glaube nicht, dass es jemals so weit kommen soll, etwas sollte es auffangen und die entsprechende JSON-Fehlerantwort zurückgeben.