Fix false-negative for UnspecifiedException when matcher is chained

[r7kamura]

I noticed that this cop could not detect the following cases, so fixed it.

expect {
  foo
}.to raise_exception.and change { bar }

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

[pirj]

Is this checking expect { |args| … }.to raise_error?
Why do we ignore if there are any, how do we care?
Do we have a an example that will fail if we remove this check?

[r7kamura]

If you want to test the raised error in detail, to may be called with a block with an argument as follows:

expect { foo }.to raise_error do |error|
  expect(error.bar).to eq("baz")
end

If this code is removed, the following test will fail:

rubocop-rspec/spec/rubocop/cop/rspec/unspecified_exception_spec.rb

Lines 70 to 78 in ce4cd77

	it 'allows classes with blocks with do/end' do
	expect_no_offenses(<<~RUBY)
	expect {
	raise StandardError.new('error')
	}.to raise_error do |error|
	error.data
	end
	RUBY
	end

[pirj]

Understood.
Such syntax is confusing as hell. The block is not passed to to, but raise_error itself, isn’t it?

I recall there’s some poke-yoke warning in RSpec warning users when the block goes actually to the wrong one.
Ps and mistake happens if you change do/end to {} 🙈

However, yes, I now recall that we decided that such syntax should be tolerated as it is expected that aome check agains what the exception is will be made inside that block.

[pirj]

Thank you!

[ydah]

Thank you!