automatic return from render and redirect

From a web application point of view, you're usually done after you deliver some content to the client, which in Rails means a render or redirect call usually.

For 99.99% of the cases, there'll be a return following a render or redirect inside some "if".

Some might prefer something like

(render login_url; return) unless authenticated?

Others will prefer something more verbose like

unless authenticated?      render login_url      return end

Others will rely on some undocumented feature of render that might change any time:

render login_url and return unless authenticated?

render (or redirect_to) is not guaranteed to return a truthy value, specially because it really doesn't make any sense for the returning result to have any meaning.

So, I'm suggesting that Rails could support some automatic "return" after each call to render or redirect_to, by calling the method inside a catch-throw block.

For example:

class Dispatcher      def dispatch(controller, action)          catch :redirected_or_rendered do              controller.send action          end      end end

class AbstractController      def render(*args) # or redirect_to          do_render(*args)          throw :redirected_or_rendered      end end

Maybe new method names like render_and_return and redirect_and_return could be added for backward compatibility, although I would really prefer to use render and redirect_to with this behavior built-in.

Maybe we could add some option like "Rails.application.config.automatic_return_from_render_or_redirect = true".

Is there any interest on adding such behavior to Rails?

Cheers,

Rodrigo.

throw/catch for flow control is bad.

Nope, I think the current way of doing things is just fine.

throw/catch for flow control is bad.

Indeed it is. It's the one thing in Sinatra I always disliked.

If I had to choose, I would go down the path of render/redirect returning a response, so you would do something like `return render :new` or `return redirect_to @object`.

This has the added bonus that it's compatible with 99.9% of the uses of render and redirect (being the last line of an action/conditional) thanks to the implicit returns.

def create   @obj = Obj.new(…)

  if @obj.save     redirect_to @obj, notice: …   else     render :new   end end

That still works as expected.

But if you did:

def create   render :foo   render :bar end

You get the response generated by "render :bar" and the other one is ignored. Because it's just an object returned, instead of some black magic depending on class state.

That said, this would require quite the refactoring in ActionPack.

But it would be much cleaner, IMHO.

Cheers, -foca

Yehuda Katz (ph) 718.877.1325

throw/catch for flow control is bad.

Indeed it is. It’s the one thing in Sinatra I always disliked.

If I had to choose, I would go down the path of render/redirect

returning a response, so you would do something like `return render

:neworreturn redirect_to @object`.

This has the added bonus that it’s compatible with 99.9% of the uses

of render and redirect (being the last line of an action/conditional)

thanks to the implicit returns.

def create

@obj = Obj.new(…)

if @obj.save

redirect_to @obj, notice: …

else

render :new

end

end

That still works as expected.

But if you did:

def create

render :foo

render :bar

end

You get the response generated by “render :bar” and the other one is

ignored. Because it’s just an object returned, instead of some black

magic depending on class state.

That said, this would require quite the refactoring in ActionPack.

It actually wouldn’t require major refactoring. The work we did in 3.0 made this possible. Unfortunately, it breaks some common scenarios:

def create

render :foo

Rails.logger.info “hi”

end

def create

@bar = “1”

lack of render here currently means implicit render, but now the return value is a String

so it would be rendered

end

etc.

raise-rescue is intended for exception handling, while catch-throw is intended for regular control flow in Ruby.

Another possible syntax would be redirect_to and render returning an object that would respond to 'and_return', like:

redirect_to(login_path).and_return unless authenticated?

This reads much better than "return render ..." and is also backward compatible...

raise-rescue is intended for exception handling, while catch-throw is intended for regular control flow in Ruby.

Right. There's a reason you don't see it often in Ruby code bases. It's slow, hard to understand, and just generally a bad idea.

Let me know if you find any performance impact on this application:

https://github.com/rosenfeld/ctbenchmark