aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorFrederik Wille <frederik@wille.hamburg>2017-03-29 15:46:10 +0200
committerFrederik Wille <frederik@wille.hamburg>2017-03-29 15:51:12 +0200
commit2b3a3738b7a519f32f593f6e6b9c6ba89daa72ea (patch)
tree9d02f1c2a5afb3a0a34ceeefb3042106f67a0acd
parent55ccec637212a2232a64f86360b2a25fa1c25759 (diff)
downloadrails-2b3a3738b7a519f32f593f6e6b9c6ba89daa72ea.tar.gz
rails-2b3a3738b7a519f32f593f6e6b9c6ba89daa72ea.tar.bz2
rails-2b3a3738b7a519f32f593f6e6b9c6ba89daa72ea.zip
add hint on after_action filters
Adds a hint that ``after_action``-callbacks are not executed when an exception was raised in the rest of the request cycle. The ``before_action`` section mentions "If there are additional filters scheduled to run after that filter, they are also cancelled." but this is IMO not sufficient.
-rw-r--r--guides/source/action_controller_overview.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/guides/source/action_controller_overview.md b/guides/source/action_controller_overview.md
index 69c4a00c5f..a43a69b7a3 100644
--- a/guides/source/action_controller_overview.md
+++ b/guides/source/action_controller_overview.md
@@ -719,7 +719,7 @@ Now, the `LoginsController`'s `new` and `create` actions will work as before wit
In addition to "before" filters, you can also run filters after an action has been executed, or both before and after.
-"after" filters are similar to "before" filters, but because the action has already been run they have access to the response data that's about to be sent to the client. Obviously, "after" filters cannot stop the action from running.
+"after" filters are similar to "before" filters, but because the action has already been run they have access to the response data that's about to be sent to the client. Obviously, "after" filters cannot stop the action from running. Please note that "after" filters are executed only after a successful action but not when an exception was raised in the request cycle.
"around" filters are responsible for running their associated actions by yielding, similar to how Rack middlewares work.