[rspec-users] no should raise_exception

[Rodrigo Rosenfeld Rosas]

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 
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/