This is interesting -- I didn't realize 1.9.3- supported rescuring an exception instance but 2.0.0 doesn't.  Good find!  I noticed something when playing around in irb:

```
2.0.0p0 :001 > $exc = StandardError.new("boom")
 => #<StandardError: boom>
2.0.0p0 :002 > def try
2.0.0p0 :003?>     raise $exc
2.0.0p0 :004?>   rescue $exc => e
2.0.0p0 :005?>     puts "Rescued #{e}"
2.0.0p0 :006?>   end
 => nil
2.0.0p0 :007 > try
TypeError: class or module required for rescue clause
	from (irb):4:in `rescue in try'
	from (irb):3:in `try'
	from (irb):7
	from /Users/myron/.rvm/rubies/ruby-2.0.0-p0/bin/irb:16:in `<main>'
2.0.0p0 :008 >
```

As the error indicates, `rescue SomeModule` is valid, too...and your `is_a?(Class)` conditional here will skip that case.

On top of that, I was just realizing that this logic will wrongly allow it to pass when you do this:

``` ruby
error = StandardError.new("foo")
expect {
  raise StandardError.new("bar")
}.to raise_error(error)
```

When a user passes an exception instance to `raise_error`, I think the expectation is that it will only pass if the raised error is `==` to the passed exception instance.  The change here will allow it to pass if the exception class is the same.

I'm thinking that we may want to do a bit of a larger refactoring of this matcher....rather than having a `rescue expected_class` and another `rescue Exception`, maybe we should just have the `rescue Exception` part, and then the actual and expected exceptions can be compared using `==` and `===`.

Regardless of the approach taken, it would be great to have additional spec coverage of the exception instance case to handle the example I put above.

(BTW, here's the 2.0.0 change: http://bugs.ruby-lang.org/issues/4438 )