Add another spec matcher for exceptions

[andrykonchin]

Feature Request

I propose to add a new spec matcher (in addition to existing #expect_raises) that would be more flexible and closer to the RSpec's #raise_error.

Examples:

# RSpec
expect { }.to raise_error
expect { }.to raise_error(ArgumentError)
expect { }.to raise_error("n must be Integer")
expect { }.to raise_error(ArgumentError, "n must be Integer")
expect { }.to raise_error(ArgumentError, /negative/)

The main functionality missing in #expect_raises() is supporting arbitrary checks on a raised exception. With #raise_error you can do so with a block argument:

# RSpec
expect { Object.new.foo }.to raise_error(ResponseError) { |error|
  expect(error.code).to eq(401)
}

There might be benefits in similarity with the RSpec's #raise_error. The #expect_raises has the following semantic differences (that might confuse a one that is familiar with RSpec):

• #expect_raises matches a given String with exception message not exactly but partially. If one needs a partial matching - it can be gained with Regex
• #expect_raises in general case matches not exception message but result of #to_s call. It allows to check exception properties other than a message. And it can be gained with a proposed block parameter.

So this way we will get a more flexible matcher and can potentially deprecate #expect_raises in future.

RSpec documentation - https://rspec.info/features/3-13/rspec-expectations/built-in-matchers/raise-error.

Related discussions - #16265

[HertzDevil]

Duplicate of #9029 (and several other issues that came before)

[andrykonchin]

Thank you for pointing at the previous discussions.

Just to be clear - this issue is not about the "expect" syntax or getting rid of monkey patching of Object. It's about new exception matcher with slightly different semantic close to RSpec's #raise_error.

[HertzDevil]

In that case, expect_raises itself returns the exception that was caught, so you could use normal matchers on the object afterwards:

error = expect_raises(ResponseError) { Object.new.foo }
error.code.should eq(401)

An example in the compiler specs:

crystal/spec/compiler/crystal_path/crystal_path_spec.cr

Lines 20 to 24 in 0c5737a

	error = expect_raises Crystal::CrystalPath::NotFoundError do
	crystal_path.find search, relative_to: relative_to
	end
	error.relative_to.should eq(expected_relative_to), file: file, line: line
	error.filename.should eq(search), file: file, line: line

So I don't think raise_error adds any expressiveness here.