[rspec-users] no should raise_exception

David Chelimsky dchelimsky at gmail.com
Mon Dec 28 15:33:06 EST 2009


On Mon, Dec 28, 2009 at 2:08 PM, rogerdpack <rogerpack2005 at gmail.com> wrote:

> > What I really want to say is "should raise(Blah)" but Ruby already
> defines
> > raise as a keyword :)
> >
> > I'd be open to aliasing raise_error with raise_exception, renaming it to
> > raise_exception and aliasing raise_error for compatibility, but I think
> this
> > might just add confusion rather than clarifying intent. Thoughts?
>
> (obviously) I like raise_exception
>
> The only drawback would be that I suppose in keeping with the new name
> it "could" be redefined to catch Exception by default, if it currently
> catches StandardError(?)
>

As luck (irony?) would have it, the default _is_ Exception. So if you alias
it in your project, you'll get what you're after.


> raise_error seems less readable to me, as there is no Error class.
>

This is sound logic, but I think it would do more harm than good at this
point.

If we were starting today, I'd probably want to have raise_exception and
raise_error, with the defaults being Exception and StandardError
respectively. That would certainly improve the accuracy of the intent
expressed in specs. The problem at this point is that it changes the meaning
of raise_error, which would lead to new failures (which cause pain), and
false positives (which cause pain you don't even know is being caused).

If we just alias raise_error with raise_exception, now we have two methods
that do the same thing, and the fact that they have names that might mean
different things to different people, I think we'd end up with more
confusion.

If we replace raise_error with raise_exception, we'd have to deprecate
raise_error, which causes pain that would be difficult to justify to many.

So we're going to leave it as raise_error for now. If you'd like to push on
this (which you're welcome to), please add a ticket to lighthouse so it's
easy to find the discussions around it. If we can get general consensus that
this would be a good move in spite of the negatives I just outlined, I'm
happy to do it.

Cheers,
David

Having both would be fine by me, too.
>
> Happy holidays.
> -r
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20091228/a6f870a2/attachment-0001.html>


More information about the rspec-users mailing list