David Chelimsky escreveu:
On Mon, Dec 28, 2009 at 2:08 PM, rogerdpack <rogerpack2...@gmail.com
<mailto:rogerpack2...@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
an error.
Best regards and have a great new year!
Rodrigo.
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
