From: Gary Wright Date: 2011-12-16T13:28:02+09:00 Subject: [ruby-core:41688] Re: Documentation of the language itself (syntax, meanings, etc) On Dec 15, 2011, at 10:39 PM, Rodrigo Rosenfeld Rosas wrote: > If returning from another method was possible, the framework could make the render method return automatically after being called, for example. That way, you would be able to simply write: > > def action > render text: "failure while creating post" unless Post.create(params) > expire_cache_from_post_list > render view: 'list' > end > > And this is much more readable to me from the perspective of someone used to web programming. It would be implicit to the developer that either "return" or "render" would stop the method execution. In frameworks that don't support rendering by convention (you must call render explicitly) it wouldn't even make sense to see a return in such action methods. Even if it were possible, you are suggesting that there should be a way for a regular method call (render in your example) to never return but instead for control to be passed back to the caller of action. I think that sort of "magic" would be very difficult to work with. There is nothing visible in the code you gave to indicate that the flow of control is radically different than what is normally expected. This seems like poor cost/benefit trade off to me. Of course there is already a standard mechanism for unwinding the stack, exceptions. By using exceptions you can sort of create the control flow you are looking for. At least this way the rescue clause is there to give the reader a hint that something unusual is happening. In this example, render_then_raise would raise ReturnNowException (yeah, bad name) to bypass the remainder of action. def action render_then_raise text: "failure while creating post" unless Post.create(params) expire_cache_from_post_list render view: 'list' rescue ReturnNowException return end Still, I don't like using exceptions as a control flow mechanism for entirely un-exceptional situations. Gary Wright