This is by intent. I never liked how returning false in a filter stops the execution. There are too many side effects, like @stuff = Model.something_returning_false, that accidentally halts the callback chain. In AJ, we're instead going for the explicit approach that requires you to raise an exception, if you want to stop execution. We'll be changing callbacks elsewhere to move away from the "false means halt" in Rails 5.0.
before_* is indeed intended to be the same as writing your code before execution, but in such a way that it can be abstracted and mixed in. So you can write before_* callbacks in super classes without having the child need to call super, or in modules that you mix in. On Wednesday, October 8, 2014 1:24:47 AM UTC+9, Claudio B. wrote: > > Hello! I have started using ActiveJob and I noticed the presence of > callbacks like before_perform. > > I was expecting these callbacks to behave like ActiveRecord ones: if a > before_* callback returns false, all the later callbacks and the associated > action are cancelled. > > That is not the case with ActiveJob, so my question is: should this be > changed? And if not… does it mean that writing code inside before_perform > is exactly the same than writing code at the beginning of the perform > method? > > Thanks! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
