We have rescue_from as well, so that'd be easy for someone to add. We can also look into adding this directly, like throwing a symbol. "throw :skip_job" or something like that. But it should be an explicit action, not a side-effect of returning false. Feel free to look into the throw option as a PR.
On Thursday, October 9, 2014 6:18:00 PM UTC+9, Andy Jeffries wrote: > > On 9 October 2014 00:00, DHH <da...@loudthinking.com <javascript:>> wrote: > >> 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. >> > > So is there a recommended exception to raise that is caught silently by > ActiveJob as just an "I've already logged the problem, raised a new job, I > just want to cancel the job as returning false would have previously" type > exception? Obviously there are plenty of cases where the problem is > handled and you just want the job cancelled but don't want the exception > bubbling up to the top and being globally logged as unhandled exception? > > Disclaimer: I haven't used ActiveJob yet... > > Cheers, > > > Andy > -- 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.
