[ruby-core:41694] Re: Documentation of the language itself (syntax, meanings, etc)

Currently this leads to messy code like
def foo
	yield(3)
end
foo{|x|
 next 42 if x==3
 x*X 
}
On Fri, Dec 16, 2011 at 02:17:36PM +0900, Yong Li wrote:
> >
> > Still, I don't like using exceptions as a control flow mechanism for entirely un-exceptional situations.
> >
> I strongly agree with this, even though I have myself met a similar
> situation in the past:
> 
> def action
>   check_input
> 
>   return if handle_special_input1_and_return  # This is valid input
> and return logic, so exception is inappropriate
> 
>   return if handle_special_input2_and_return
> 
>   handle_common_cases
> end
> 
> I did not want to inline "handle_special_inputx_and_return" because it
> would make the action method too long and blur the main logic.
> However, extracting them to private methods would make the code more
> verbose as I cannot return "action" from within
> "handle_special_input_and_return", and this forces me to return a
> value from "handle_special_input_and_return" and check them in
> "action".
> 
> I was also trying hard to get around this, but finally settled on this
> for the following reasons:
> * The only way to break out multiple levels of code (nested methods or
> loops or both) is to use a "go-to" like operation, which allows you to
> jump to anywhere in you code. Exceptions can be used for this purpose.
> But again, this is very bad.
> * go-to operations are rarely good to use
> * the purpose and condition of return is clear and explicit, which
> reduces confusions for other people
> 
> Maybe I could re-design my code to avoid such situations in the first
> place, but that would be a completely different story.
> 
> I would be very glad to hear a more succinct solution and throw my
> silly argument under the bus :-D

-- 

Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet.