Deprecate `expect { }.not_to raise_error(SpecificErrorClass)` #244

fables-tales · 2013-04-21T16:43:51Z

Related #231.

Deprecates raising with a specific error class and adds specs for this. Also a spec to ensure that the deprecation does not affect using this with a specific error class.

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

myronmarston · 2013-04-22T05:55:42Z

lib/rspec/matchers/built_in/raise_error.rb

@@ -14,6 +14,10 @@ def initialize(expected_error_or_message=Exception, expected_message=nil, &block
        end

        def matches?(given_proc, negative_expectation = false)
+          if negative_expectation == :negative_expectation && @expected_error != Exception


You can just check if negative_expectation -- no need to compare it to the symbol. At the call site it passes the symbol because that's more expressive than passing true (which doesn't mean a whole lot on its own).

Also, what do you think about extracting the @expected_error != Exception part into a method that expresses it better? Maybe something like expecting_specific_exception?

Also, what do you think about extracting the @expected_error != Exception part into a method that expresses it better? Maybe something like expecting_specific_exception?

👍

fables-tales · 2013-04-22T23:39:31Z

Myron these are all great catches as usual. I'm currently facing the last 3 weeks of writing my master's thesis so expect very intermittent stuff from me.

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

includes breaking out an "expecting_specific_exception?" query. Signed-off-by: Sam Phippen <samphippen@googlemail.com>

JonRowe · 2013-04-24T23:29:44Z

lib/rspec/matchers/built_in/raise_error.rb

@@ -14,6 +14,13 @@ def initialize(expected_error_or_message=Exception, expected_message=nil, &block
        end

        def matches?(given_proc, negative_expectation = false)
+          if negative_expectation && expecting_specific_exception?
+            p "warning deprecation"


Extraneous puts?

Yup! This is now gone.

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

JonRowe · 2013-04-24T23:58:05Z

Looks good to me, merge away

fables-tales · 2013-04-24T23:58:30Z

Cool.

…error-class Deprecate `expect { }.not_to raise_error(SpecificErrorClass)`

dchelimsky · 2013-05-16T17:18:17Z

I'm updating the spec for this and noticed that expect { .. }.not_to raise_error(message) is still supported. I think we should deprecate that as well based on the same motivation described in #231. WDYT?

fables-tales · 2013-05-16T17:26:14Z

@dchelimsky 👍

myronmarston · 2013-05-16T17:47:27Z

Great idea.

On Thu, May 16, 2013 at 10:26 AM, Sam Phippen notifications@github.comwrote:

@dchelimsky https://github.com/dchelimsky [image: 👍]

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18015854
.

dchelimsky · 2013-05-16T17:50:46Z

Building now on a separate branch: https://github.com/rspec/rspec-expectations/compare/deprecate-not-to-raise-error-with-message

There are some other issues addressed on that branch, but unless there is objection I'm just going to merge the branch once travis says it's OK to do so.

dchelimsky · 2013-05-16T17:57:15Z

Travis failed the build due to a failing cuke, but the same cuke is failing on master - looking into it.

myronmarston · 2013-05-16T17:57:22Z

Two things (I can't figure out how to comment on that view, sadly):

Nice to see usage of the new syntax :).
I noticed the deprecation warning is expect { }.not_to raise_error(SpecificErrorClass) for both the raise_error(SomeClass) and
raise_error("Some message") case. That's potentially confusing. Maybe
it should just be raise_error(something) or separate messages for these
two cases?

Thanks for taking care of this!

On Thu, May 16, 2013 at 10:50 AM, David Chelimsky
notifications@github.comwrote:

Building now on a separate branch:
https://github.com/rspec/rspec-expectations/compare/deprecate-not-to-raise-error-with-message

There are some other issues addressed on that branch, but unless there is
objection I'm just going to merge the branch once travis says it's OK to do
so.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18017414
.

dchelimsky · 2013-05-16T18:00:10Z

I'll clarify the failure message. Thx.

dchelimsky · 2013-05-16T18:10:31Z

The current travis failure is due to this:

  1) using the expect syntax
     Failure/Error: specify { expect(3).to eq(3) }
       only the `receive` matcher is supported with `expect(...).to`, but you have provided: #<RSpec::Matchers::BuiltIn::Eq:0x007fb5792e5758>
     # ./syntaxes_spec.rb:9:in `block (2 levels) in <top (required)>'

This suggests that the new message expectation syntax is spec'd to disallow any matcher besides receive to expect(obj).to, which breaks on expect(obj).to eq, but there is only one failing cuke at the moment (I'd expect a lot more failures). I'll follow up in a bit as I learn, but if any of you have any insights on this, out with them, please!

myronmarston · 2013-05-16T18:16:24Z

I know a bit about that. It's generated here:

https://github.com/rspec/rspec-mocks/blob/master/lib/rspec/mocks/targets.rb#L11-L21

That error should only be raised if the :expect syntax is enabled in rspec-mocks but disabled in rspec-expectations (or if you're using rspec-mocks standalone w/o rspec-expectations). Sounds like there's a bug somewhere in that logic...

dchelimsky · 2013-05-16T18:19:15Z

I added this to the cuke and it passed:

```
   config.mock_with :rspec do |c|
```
```
     c.syntax = :should
```
```
   end
```

Make sense to you, @myronmarston?

On Thu, May 16, 2013 at 1:16 PM, Myron Marston notifications@github.comwrote:

I know a bit about that. It's generated here:

https://github.com/rspec/rspec-mocks/blob/master/lib/rspec/mocks/targets.rb#L11-L21

That error should only be raised if the :expect syntax is enabled in
rspec-mocks but disabled in rspec-expectations (or if you're using
rspec-mocks standalone w/o rspec-expectations). Sounds like there's a bug
somewhere in that logic...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18019083
.

myronmarston · 2013-05-16T18:52:21Z

Yep, thanks for fixing that!

On Thu, May 16, 2013 at 11:19 AM, David Chelimsky
notifications@github.comwrote:

I added this to the cuke and it passed:

config.mock_with :rspec do |c|

c.syntax = :should

end

Make sense to you, @myronmarston?

On Thu, May 16, 2013 at 1:16 PM, Myron Marston notifications@github.comwrote:

I know a bit about that. It's generated here:

https://github.com/rspec/rspec-mocks/blob/master/lib/rspec/mocks/targets.rb#L11-L21

That error should only be raised if the :expect syntax is enabled in
rspec-mocks but disabled in rspec-expectations (or if you're using
rspec-mocks standalone w/o rspec-expectations). Sounds like there's a
bug
somewhere in that logic...

—
Reply to this email directly or view it on GitHub<
https://github.com/rspec/rspec-expectations/pull/244#issuecomment-18019083>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18019299
.

dchelimsky · 2013-05-16T19:03:39Z

@myronmarston b956215

WDYT?

myronmarston · 2013-05-16T19:12:13Z

Looks great!

On Thu, May 16, 2013 at 12:03 PM, David Chelimsky
notifications@github.comwrote:

@myronmarston https://github.com/myronmarston b956215b956215a0d12

WDYT?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18022090
.

sethvargo · 2013-07-14T20:15:34Z

@myronmarston how does one assert that a function raises a certain type of error then? Especially when working on a CLI application, just checking that something raises an error is not enough - I need to check if the error is actually X, not Y. Is there a replacement to this method then?

cupakromer · 2013-07-14T20:57:41Z

@sethvargo You can still do that:

expect{}.to raise_error(ArgumentError)

What is being deprecated is the negation:

expect{}.not_to raise_error(ArgumentError)

to vs not_to/to_not. The reason is the negative version is brittle. You could raise all kinds of errors that no longer meet the matcher after a code change, but the test will still pass (false positive). Instead for the negative version you should just expect nothing is raised.

sethvargo · 2013-07-14T21:11:33Z

Ahh okay. That's a bit confusing. Thanks!

Checking that a specifc error is not raised is deprecated in rspec: rspec/rspec-expectations#244

according to: rspec/rspec-expectations#244, expecting a specific error to not be raised is deprecated and not really a good idea. Indeed, I found two other testcases where a different error was being raised other than the one we specified. I will fix those in later commits.

Sam Phippen added 2 commits April 21, 2013 17:41

Deprecate expect { }.not_to raise_error(SpecificErrorClass)

dccf4aa

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

Add a changelog entry for rspec#244

6fb8361

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

myronmarston reviewed Apr 22, 2013
View reviewed changes

Sam Phippen added 2 commits April 25, 2013 00:16

Break excessively long line up in raise_error

e7e394c

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

Fix conditionals for raise_error deprecation

dd0e665

includes breaking out an "expecting_specific_exception?" query. Signed-off-by: Sam Phippen <samphippen@googlemail.com>

JonRowe reviewed Apr 24, 2013
View reviewed changes

Sam Phippen added 4 commits April 25, 2013 00:29

Fix up raise_error specs for specific error class deprecation

1d6a867

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

Add an extra space between expect and {} in raise_error

d7374d6

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

Add backticks to the raise_error(SomeClass) error message.

06969b2

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

Remove a debugging print in raise_error

919e105

Signed-off-by: Sam Phippen <samphippen@googlemail.com>

fables-tales pushed a commit that referenced this pull request Apr 24, 2013

Merge pull request #244 from samphippen/deprecate-not-raise-specific-…

ddb0b7c

…error-class Deprecate `expect { }.not_to raise_error(SpecificErrorClass)`

fables-tales merged commit ddb0b7c into rspec:master Apr 24, 2013

fables-tales mentioned this pull request Apr 24, 2013

Consider deprecating expect { }.not_to raise_error(SpecificErrorClass) #231

Closed

fables-tales deleted the deprecate-not-raise-specific-error-class branch April 27, 2013 21:24

yujinakayama mentioned this pull request Aug 17, 2013

Support conversion from not_to raise_error(SpecificErrorClass) to not_to raise_error yujinakayama/transpec#2

Closed

schierlm pushed a commit to schierlm/metasploit-framework that referenced this pull request Nov 3, 2013

Remove rpsec should_not raise_error deprecations

cf69577

Checking that a specifc error is not raised is deprecated in rspec: rspec/rspec-expectations#244

tgxworld mentioned this pull request Dec 17, 2018

FEATURE: Prohibit S3 bucket reusage discourse/discourse#6783

Merged

pirj mentioned this pull request Jun 5, 2020

Let's change the default for RSpec/PredicateMatcher rubocop/rubocop-rspec#919

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Deprecate `expect { }.not_to raise_error(SpecificErrorClass)` #244

Deprecate `expect { }.not_to raise_error(SpecificErrorClass)` #244

fables-tales commented Apr 21, 2013

myronmarston Apr 22, 2013

JonRowe Apr 22, 2013

fables-tales commented Apr 22, 2013

JonRowe Apr 24, 2013

fables-tales Apr 24, 2013

JonRowe commented Apr 24, 2013

fables-tales commented Apr 24, 2013

dchelimsky commented May 16, 2013

fables-tales commented May 16, 2013

myronmarston commented May 16, 2013

dchelimsky commented May 16, 2013

dchelimsky commented May 16, 2013

myronmarston commented May 16, 2013

dchelimsky commented May 16, 2013

dchelimsky commented May 16, 2013

myronmarston commented May 16, 2013

dchelimsky commented May 16, 2013

myronmarston commented May 16, 2013

dchelimsky commented May 16, 2013

myronmarston commented May 16, 2013

sethvargo commented Jul 14, 2013

cupakromer commented Jul 14, 2013

sethvargo commented Jul 14, 2013

Deprecate expect { }.not_to raise_error(SpecificErrorClass) #244

Deprecate expect { }.not_to raise_error(SpecificErrorClass) #244

Conversation

fables-tales commented Apr 21, 2013

myronmarston Apr 22, 2013

Choose a reason for hiding this comment

JonRowe Apr 22, 2013

Choose a reason for hiding this comment

fables-tales commented Apr 22, 2013

JonRowe Apr 24, 2013

Choose a reason for hiding this comment

fables-tales Apr 24, 2013

Choose a reason for hiding this comment

JonRowe commented Apr 24, 2013

fables-tales commented Apr 24, 2013

dchelimsky commented May 16, 2013

fables-tales commented May 16, 2013

myronmarston commented May 16, 2013

dchelimsky commented May 16, 2013

dchelimsky commented May 16, 2013

myronmarston commented May 16, 2013

dchelimsky commented May 16, 2013

dchelimsky commented May 16, 2013

myronmarston commented May 16, 2013

dchelimsky commented May 16, 2013

myronmarston commented May 16, 2013

dchelimsky commented May 16, 2013

myronmarston commented May 16, 2013

sethvargo commented Jul 14, 2013

cupakromer commented Jul 14, 2013

sethvargo commented Jul 14, 2013

Deprecate `expect { }.not_to raise_error(SpecificErrorClass)` #244

Deprecate `expect { }.not_to raise_error(SpecificErrorClass)` #244