diff options
| author | Frederik Wille <frederik@wille.hamburg> | 2017-03-29 15:46:10 +0200 |
|---|---|---|
| committer | Frederik Wille <frederik@wille.hamburg> | 2017-03-29 15:51:12 +0200 |
| commit | 2b3a3738b7a519f32f593f6e6b9c6ba89daa72ea (patch) | |
| tree | 9d02f1c2a5afb3a0a34ceeefb3042106f67a0acd /guides/source/action_controller_overview.md | |
| parent | 55ccec637212a2232a64f86360b2a25fa1c25759 (diff) | |
| download | rails-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.
Diffstat (limited to 'guides/source/action_controller_overview.md')
| -rw-r--r-- | guides/source/action_controller_overview.md | 2 |
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. |