raise_error behavior change under Ruby 2

[jjb]

I'm seeing a behavior change when running under Ruby 2.0.

I have specs that looks like this. To make them pass under Ruby 2, I had to make the change noted in the comment near the end.

it "reraises the exception" do
  error = ActiveRecord::RecordInvalid.new(record)
  foos.should_receive(:create!).
    and_raise(error)
  expect{
    bar.create_foo(baz_id: baz_id)
  }.to raise_error(error) # this works as expected in 1.9.3
  # }.to raise_error(ActiveRecord::RecordInvalid) # i had to switch to this for 2.0.0
end

Is this expected? Is this because of a fundamental change in Ruby 2, or a bug in how rspec interacts with it?

Let me know if you want more info.

rails is 3.2.13

[myronmarston]

It's not expected or previously known. Can you come up with an isolated example that demonstrates this?

[jjb]

@myronmarston ta-da! https://github.com/jjb/rspec-expectations-issue-232

see spec/models/foo_spec.rb

[jjb]

and here's the output of running specs under each version

➔ rbenv shell 1.9.3-p385-perf 
➔ rspec --format=documentation

Foo
  this spec works in both 1.9.3 and 2.0.0
  this spec works in 1.9.3 only

Finished in 0.00761 seconds
2 examples, 0 failures

Randomized with seed 23056

➔ rbenv shell 2.0.0-p0 
➔ rspec --format=documentation

Foo
  this spec works in both 1.9.3 and 2.0.0
  this spec works in 1.9.3 only (FAILED - 1)

Failures:

  1) Foo this spec works in 1.9.3 only
     Failure/Error: expect{subject.bar}.to raise_error(error)
       expected StandardError but nothing was raised
     # ./spec/models/foo_spec.rb:15:in `block (2 levels) in <top (required)>'

Finished in 0.01049 seconds
2 examples, 1 failure

Failed examples:

rspec ./spec/models/foo_spec.rb:14 # Foo this spec works in 1.9.3 only

Randomized with seed 2069

[fables-tales]

I'm going to try and isolate/fix this today

[fables-tales]

I've isolated this to line 23 of this file

[jjb]

@samphippen nice. i wonder why ruby 2 caused that behavior to change thought...

[myronmarston]

@jjb: it got changed here:

http://bugs.ruby-lang.org/issues/4438

[jjb]

interesting ​-- although i can't really tell from that thread what the
decided behavior change was.

i haven't seen this issue discussed anywhere else on the web

/cc @avdi

[avdi]

Well that ticks me off. I can't think of any good reason to require that thing to be a class or module.

[JonRowe]

So this'll be fixed when #236 is merged, which will be fixed when #239 is merged? :)