[rspec-users] no should raise_exception
Rodrigo Rosenfeld Rosas
lbocseg at yahoo.com.br
Mon Dec 28 20:12:13 EST 2009
David Chelimsky escreveu:
> On Mon, Dec 28, 2009 at 2:08 PM, rogerdpack <rogerpack2005 at gmail.com
> <mailto: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.
Maybe a voting process would be a good idea... But where to get visibility?
I don't think a deprecation would cause that much of pain, once it is
justified in a changelog. Maybe it would be a change for the next major
version, where people are more willing to accept major changes...
My vote would be to include raise_exception (independently to aliasing
it or not) as the specs turns out more concise when the exception is not
Best regards and have a great new year!
Faça ligações para outros computadores com o novo Yahoo! Messenger
More information about the rspec-users