After upgrading to RuboCop 0.50, we are seeing RescueWithoutErrorClass being raised for code that _does_ actually provide an error class:
lib/ecraft/sequel_library/sequel_session_store.rb:148:105: W: Lint/RescueWithoutErrorClass: Avoid rescuing without specifying an error class.
Ecraft::WebApi::SessionManager.register_store(:postgres, Ecraft::SequelLibrary::SequelSessionStore) rescue NameError # rubocop:disable RescueModifier, LineLength
Rubocop should accept this code, since it provides an error class (NameError).
Rubocop produced a Lint/RescueWithoutErrorClass warning.
Probably the following will do, if not, the exact example above:
puts 'hello' rescue NameError
Include the output of rubocop -V. Here's an example:
Fetching rubocop 0.50.0
(don't have rubocop -V output since this was running on Travis.)
Looks like the parsed AST is different when using a rescue modifier. Working on a fix.
I don't think rescue as a modifier works the way @perlun thinks it works.
irb(main):018:0> 3 / 0 rescue NameError
=> NameError
I don't know of a syntax that allows the modifier form of rescue to be restricted to a particular class. If there isn't one, then it might make sense to simply not have rubocop complain about the error class when using the modifier form.
You're right @ctm. This cop should just ignore modifier form rescue. (It is handled by the RescueModifier cop.) PR incoming.
@ctm Hehe, very good point! 馃槅 Thanks for pointing that out. I need to fix my code...
Most helpful comment
I don't think rescue as a modifier works the way @perlun thinks it works.
I don't know of a syntax that allows the modifier form of rescue to be restricted to a particular class. If there isn't one, then it might make sense to simply not have rubocop complain about the error class when using the modifier form.