Browse files

Remove the bit about rescue_action

  • Loading branch information...
toretore committed Oct 8, 2008
1 parent b4da5f6 commit 49c0b127e69cb280c3ab1fd465362e2631bd2b99
Showing with 0 additions and 24 deletions.
  1. +0 −24 railties/doc/guides/actioncontroller/rescue.txt
@@ -66,30 +66,6 @@ end
NOTE: Certain exceptions are only rescuable from the ApplicationController class, as they are raised before the controller gets initialized and the action gets executed. See Partik Naik's link:[article] on the subject for more information.
-=== `rescue_action` ===
-The `rescue_from` method was added to make it easier to rescue different kinds of exceptions and deal with each separately. Action Controller has a default method which intercepts *all* exceptions raised, `rescue_action`. You can override this method in a controller or in ApplicationController to rescue all exceptions raised in that particular context. You can get a little bit more granular by using the link:[rescue_action_in_public] and link:[rescue_action_locally] methods which are used to rescue actions for public and local requests. Let's see how the User::NotAuthorized exception could be caught using this technique:
-[source, ruby]
-class ApplicationController < ActionController::Base
- def rescue_action_in_public(exception)
- case exception
- when User::NotAuthorized
- user_not_authorized
- else
- super
- end
- end
-As you can see, this gets a bit messy once you start rescuing various types of error that require separate handlers, so it's a good idea to use `rescue_from` instead.
=== Getting down and dirty ===
Of course you can still use Ruby's `rescue` to rescue exceptions wherever you want. This is usually constrained to single methods, i.e. actions, but is still a very useful technique that should be used when appropriate. For example, you might use an API that raises a timeout error in one of your actions, and you have to handle that if it's raised:

0 comments on commit 49c0b12

Please sign in to comment.