remove fail/raise section

[johnny]

The distinction between fail and raise is artificial.

Plus fail is not prominent.

[bbatsov]

They are equivalent indeed, but the use of both of them is pretty popular. It was coined a while back by @jimweirich and popularized by Avdi Grimm in his book "Exceptional Ruby". Basically the idea is that by combining fail and raise you're quickly able to discern whether you have an exceptional condition or are simply re-raising an exception. Semantic rules are pretty handy, especially those that can be enforced automatically (like this one).

[fuadsaud]

@bbatsov agreed.

[johnny]

Then let me elaborate my reasoning:

First, I am not a native speaker but to me it seems there is no difference between the following two sentences:

If the connection does not respond, fail with an exception.
If the connection does not respond, raise an exception.

If there is no distinction, there is a certain arbitrariness associated with this rule ("Wait, was it fail to reraise an exception or the other way around"). You would have to memorize this non-intuitive rule. But perhaps there is a real semantic difference I am not aware of (and other non-native speakers, too)

Second, reraising an exception happens in a rescue block most of the time. Since those should be small, the semantic benefit is non existent.

Third, fail is not a keyword and there are projects which overwrite it (EventMachine::Deferrable comes to mind). The rule can't be enforced, if you use those libraries.

For me, this project is a collection of the common best practices and some less prominent rules which are sensible on second thought. The raise/fail distinction is neither. Please do not cross the line JSlint crossed long ago (and mirror personal preferences)

Edit: ensure > rescue

[fuadsaud]

I'm unsure about this also.

[bbatsov]

1. You don't fail with an exception - you fail, and the by-product of that is an exception.
2. Re-raising an exception happens most of the time in a rescue block, and almost never in an ensure block. Re-raising happens quite often, although not quite as often as signaling exceptions.
3. raise is not a keyword either...

[johnny]

1. Fail allows the same parameters as raise. If you specify an exception class, my sentence still stands.
2. I meant rescue block. I do not get your second sentence. Does it address my point of the distinction not having a semantic value?
3. raise is accepted universally (and found in every textbook) and I have not seen this overwritten in such a way, that a raise call does not work as expected. fail in Eventmachine::Deferrable on the other hand behaves different and does not raise an exception. http://eventmachine.rubyforge.org/EventMachine/Deferrable.html#fail-instance_method

BTW: I have "The Ruby Programming Language" by Mats himself right in front of me, and fail isn't even mentioned once.

[bbatsov]

1. Yep, I never said anything else. Semantic rules are called semantic for a reason :-)
2. I meant that re-raising exceptions from rescue does not happen as infrequently as you said.
3. Books are often a poor substitute for real coding experience :-) Messing with Kernel methods is not a good idea, no matter who does it - people have some strong expectations how these methods should behave... Someone could have overriden raise as well...

As for the book - it's widely marketed as being written by Matz, but I'm pretty sure David Flanagan is the principle author (having read his JavaScript book as well). That's not to say it's not a great book - but it's not some universal truth. For instance they use a terrible convention for blocks {|x| something(x) }, that I've never seen in the wild. And fail is mentioned at least once (on page 31) :-)

I don't deny raise's popularity, but I ask you to think about this - is popular equal to being good? The use of raise vs fail is a fairly trivial matter. If you disagree with it that strongly I guess you should just disregard that particular advice.

[johnny]

1. So we agree: there is no semantic difference between fail and raise (if you provide an error class).
2. What I wrote is that the rescue blocks are small and easily digestible. Therefore you do not need the extra hint of fail vs raise.
3. Your reply is missing my point, which is: raise works as expected almost everywhere, fail doesn't

My principal problem with the fail/raise distinction is, that it adds something to the language which is not obvious and seems arbitrary (See point 1.) and provides no benefit (2) with potential harm/confusion (3).

P.S.: I should not have brought up the book. It seems you did focus too much on it and missed my point. Since you referred to authorities in your first reply, I thought other authorities might convince you.

[fuadsaud]

" You don't fail with an exception - you fail, and the by-product of that
is an exception."
I like this. fail reads as "something went wrong, I need to notify this"
while raise feels like an implementation detail of error handling.

Btw, overriding Kernel methods feels hacky hackyish, and changing their
semantics is something very very bad.
On Oct 15, 2013 5:39 AM, "Jonas von Andrian" notifications@github.com
wrote:

1. So we agree: there is no semantic difference between fail and raise
   (if you provide an error class).
2. What I wrote is that the rescue blocks are small and easily
   digestible. Therefore you do not need the extra hint of fail vs raise.
3. Your reply is missing my point, which is: raise works as expected
   almost everywhere, fail doesn't

My principal problem with the fail/raise distinction is, that it adds
something to the language which is not obvious and seems arbitrary (See
point 1.) and provides no benefit (2) with potential harm/confusion (3).

P.S.: I should not have brought up the book. It seems you did focus too
much on it and missed my point. Since you referred to authorities in your
first reply, I thought other authorities might convince you.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/233#issuecomment-26317781
.

[johnny]

@fuadsaud again, this reasoning only works, if you do not specify an exception class.

fail 'something went wrong'

This reads nicely, and your reasoning might work there, but it falls apart if you try to apply it in the following

fail SomeErrorClass, 'something went wrong'

Once you specify an error class, you have an "implementation detail of error handling"

[krainboltgreene]

Bleh, so it just changed all my raises to fails and I really don't see the added value in the changes it made:

raise IndexError if empty? or index == @size
raise IndexError if index.abs > @size

vs

fail IndexError if empty? or index == @size
fail IndexError if index.abs > @size

I can totally see fail being substituted if the argument passed is a string (as seen in the comment above), but if I'm passing an Exception class I fully expect to see raise.

For what it's worth, I've never seen fail used in 5 years of (near exclusive) Ruby programming.

[denisdefreyne]

+1 for removing the fail/raise section. I’ve never seen fail used anywhere either.

[krainboltgreene]

Rather than removing it completely I suggest:

1. Taking the autocorrect out
2. Only failing on raise "some message"

[bbatsov]

@krainboltgreene Assuming you're referring to RuboCop's autocorrect - the behavior is configurable (you can make it enforce raise everywhere for instance).

Maybe it makes sense to use fail only when having a single string argument. I have to think more about this, though.

[bf4]

I agree with @bbatsov above, #233 (comment), use fail to create a new exception, use raise when one has already been created (usually in a rescue block).

That way, fail always means you are declaring a new failure in some expectation and raise means you are either changing the exception type or re-raising the exception after some processing.