Raise_error suggestion

I remember reading a post where somebody mentioned something like

"sometimes after a refactoring, a test block like

 lambda { ... }.should raise_error

catches a NoMethodError in error, thus is actually failing, but the
user isn’t notified of the same."

A suggestion in this regard:
change it so that if raise_error is called without parameters, and it
catches NoMethodError, it outputs a warning somehow.

The objection to this might be “what if I expect a NoMethodError–
I’ll get spurious warnings”

Answer: user can, at that point, put in NoMethodError as a parameter,
and warning goes away (and that’s a rare enough case that it probably
won’t cause conflicts).

Thoughts?
Thanks!
-rp

On Wed, Apr 14, 2010 at 2:28 PM, rogerdpack [email protected]
wrote:

change it so that if raise_error is called without parameters, and it
catches NoMethodError, it outputs a warning somehow.

Thoughts?

+1; I have been burned by this several times, and this is seems like
an elegant solution to clear up the potential confusion in this
behavior. Less confusion = happier devs

Cheers,

Paul

On Apr 14, 2010, at 12:28 PM, rogerdpack wrote:

change it so that if raise_error is called without parameters, and it
catches NoMethodError, it outputs a warning somehow.

The objection to this might be “what if I expect a NoMethodError–
I’ll get spurious warnings”

Answer: user can, at that point, put in NoMethodError as a parameter,
and warning goes away (and that’s a rare enough case that it probably
won’t cause conflicts).

Be explicit about the error you expect to get:

lambda { … }.should raise_error(SomeErrorClass, /match the message/)

Read the documentation at
http://rspec.rubyforge.org/rspec/1.3.0/classes/Spec/Matchers.html#M000184

Nothing kills me more than a generic raise_error. Especially when the
block is wrapped around a whole bunch of code that doesn’t need it e.g.

lambda {
some_setup
some_setup
some.stupid_typo_that_blows_up
call_that_we_expect_to_raise_an_error
}.should raise_error

Anyone on my team using a naked raise_error matcher gets a smack on the
head from me…and I have a special spiky dunce cap for whoever does the
above example.

Also note in RSpec 1.3.0 #lambda is aliased to #expect, and #should to
#to, so you can do

expect { … }.to raise_error(SomeErrorClass, /match the message/)

which you may find more pleasant to read.

Pat

Be explicit about the error you expect to get:

lambda { … }.should raise_error(SomeErrorClass, /match the message/)

Read the documentation athttp://rspec.rubyforge.org/rspec/1.3.0/classes/Spec/Matchers.html#M00…

Perhaps it should be changed so that if you don’t pass a class it
outputs a warning. That might be an acceptable option. (If not then I
still recommend my previous suggestion).
Thanks!
-rp

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs