Suggestion: Prefer to _not_ use two argument version of raise

[rhys-vdw]

Just hit this surprising behavior of raise.

These two lines are not equivalent:

raise SomeError, "a", "b"
raise SomeError.new("a", "b")

In the former case the third argument will be silently ignored causing an error like this:

ArgumentError: wrong number of arguments (given 1, expected 2)

This is a confusion can be avoided by simply calling new directly. (Also IMO is clearer about what's really happening when you call raise, a simple object construction.)

Alternatively a Rubocop rule could be introduced to detect when more than two arguments are passed to raise.

[rhys-vdw]

Upon further investigation we had disabled the rule instead of setting it to "EnforcedStyle: compact". I would still suggest a change in default, but it seems that Rubocop has this covered.

Nice. 👌

[rhys-vdw]

Actually, can I suggest that this gets split into two rules:

• One rule that prevents more than two arguments being passed to raise. This is to enforce a non-obvious behaviour of Ruby highlighted above.
• Another rule that is stylistic and suggests using raise A, a instead of raise A.new(a).

I think this is a more sensible approach. Because now I can't enable the rule without changing all instances.

[bbatsov]

I'm totally open to improving the existing rule.

Keep in mind the following:

With no arguments, raises the exception in $! or raises a RuntimeError if $! is nil. With a single String argument, it raises a RuntimeError with the string as a message. Otherwise, the first parameter should be the name of an Exception class (or an object that returns an Exception when sent exception). The optional second parameter sets the message associated with the exception, and the third parameter is an array of callback information. Exceptions are caught by the rescue clause of begin...end blocks.

I think it's mostly a matter of misaligned expectations.

[pirj]

Related rubocop/rubocop#8175

[pirj]

Tracked in #395