Style/SignalException is bit too inclusive about the fail scope

[SaltwaterC]

I am glad that the great debate about raise/fail is finally over, having to refactor my code in the process (see #2732). However, Style/SignalException shouldn't really apply to this piece of code:

require 'term/ansicolor'

# doc
class Colour
  extend Term::ANSIColor
end

# doc
class Foo
  def self.foo
    fail 'nice reason for failing instead of ugly stack trace'
  end

  def self.fail(msg)
    STDERR.print Colour.red, "Fatal: #{msg}!", Colour.reset
    STDERR.puts
    Kernel.exit 1
  end
end

Foo.foo

By trying to workaround the issue with:

self.fail 'nice reason for failing instead of ugly stack trace'

There's:

$ rubocop
Inspecting 1 file
C

Offenses:

code.rb:11:5: C: Redundant self detected.
    self.fail 'nice reason for failing instead of ugly stack trace'
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

1 file inspected, 1 offense detected

2010 really want their memes back, but I was ready to drop a rageface over this one.

LE: forgot to add this:

0.37.2 (using Parser 2.3.0.5, running on ruby 2.1.6 x86_64-darwin12.0)

[alexdowad]

There's no way we can possibly detect every situation where fail calls something other than Kernel#fail. But maybe we can filter out some trivial cases, like this one. Maintainers, what do you think?

[bbatsov]

I think it's not a good idea to shadow Kernel methods. Maybe this deserves a cop. ;-)

This is the first time someone reports such an issue in 3 years, so I'm not sure whether it's worth investing any efforts here. On the other hand - trivial cases should be easy to handle.

[alexdowad]

trivial cases should be easy to handle.

The question is, if someone wants to define a custom fail method, what are the chances they will only use it in the file which defines it?

[SaltwaterC]

The consumers of my utility class use Foo.fail instead of (Kernel.)fail, therefore it's not really an issue as there's no namespace conflict. As you can see, my utility class is made of static methods, but some methods in Foo may call the fail method defined in its scope which triggers this issue in RuboCop.

If this deserves a cop, I'm OK with it.

[bbatsov]

I should have read the example code. :-) This would be easy to fix.

[alexdowad]

What if we don't flag any call to fail with an explicit receiver?

[alexdowad]

What if we don't flag any call to fail with an explicit receiver?

Uhh... that's what we already do. Forget what I said.