[#41431] [ruby-trunk - Bug #5694][Open] Proc#arity doesn't take optional arguments into account. — Marc-Andre Lafortune <ruby-core@...>

27 messages 2011/12/01
[#41442] [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account. — Thomas Sawyer <transfire@...> 2011/12/01

[#41443] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account. — Yehuda Katz <wycats@...> 2011/12/01

Maybe we can add a new arity_range method that does this?

[#41496] [ruby-trunk - Bug #5714][Open] Unexpected error of STDIN#read with non-ascii input on Windows XP — Heesob Park <phasis@...>

22 messages 2011/12/06

[#41511] [ruby-trunk - Bug #5719][Open] Hash::[] can't handle 100000+ args — Nick Quaranto <nick@...>

13 messages 2011/12/07

[#41557] [ruby-trunk - Bug #5730][Open] Optinal block parameters assigns wrong — Yukihiro Matsumoto <matz@...>

14 messages 2011/12/08

[#41586] [ruby-trunk - Feature #5741][Open] Secure Erasure of Passwords — Martin Bosslet <Martin.Bosslet@...>

17 messages 2011/12/10

[#41672] [ruby-trunk - Feature #5767][Open] Cache expanded_load_path to reduce startup time — Yura Sokolov <funny.falcon@...>

13 messages 2011/12/15

[#41681] Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...>

Since Ruby is built on top of simple concepts, most of the documentation

23 messages 2011/12/15
[#41683] Re: Documentation of the language itself (syntax, meanings, etc) — Gary Wright <gwtmp01@...> 2011/12/15

[#41686] Re: Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2011/12/16

Em 15-12-2011 19:23, Gary Wright escreveu:

[#41717] Feature : optional argument in File.join — Michel Demazure <michel@...>

In Windows, when using File.join, one often ends with a path containing

13 messages 2011/12/19
[#41719] Re: Feature : optional argument in File.join — Luis Lavena <luislavena@...> 2011/12/19

On Mon, Dec 19, 2011 at 6:09 AM, Michel Demazure <michel@demazure.com> wrot=

[#41720] Re: Feature : optional argument in File.join — Michel Demazure <michel@...> 2011/12/19

Luis Lavena wrote in post #1037331:

[#41728] [ruby-trunk - Feature #5781][Open] Query attributes (attribute methods ending in `?` mark) — Thomas Sawyer <transfire@...>

15 messages 2011/12/19

[#41799] Best way to separate implementation specific code? — Luis Lavena <luislavena@...>

Hello,

15 messages 2011/12/24
[#41800] Re: Best way to separate implementation specific code? — KOSAKI Motohiro <kosaki.motohiro@...> 2011/12/24

2011/12/24 Luis Lavena <luislavena@gmail.com>:

[#41811] Re: Best way to separate implementation specific code? — "U.Nakamura" <usa@...> 2011/12/26

Hello,

[#41817] Re: Best way to separate implementation specific code? — Luis Lavena <luislavena@...> 2011/12/26

On Sun, Dec 25, 2011 at 10:51 PM, U.Nakamura <usa@garbagecollect.jp> wrote:

[#41812] [ruby-trunk - Feature #5809][Open] Benchmark#bm: remove the label_width parameter — Benoit Daloze <redmine@...>

11 messages 2011/12/26

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

From: Peter Vandenabeele <peter@...>
Date: 2011-12-16 08:33:21 UTC
List: ruby-core #41695
On Fri, Dec 16, 2011 at 6:17 AM, Yong Li <gilbertly@gmail.com> 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
>


Certainly a problem I was also bitten by this more than I wanted ...

The problem:

(meta-code)

def show
  user = User.find(params[:id])
  if user.secret?
    flash[:warning] = "sorry, this is secret"
    redirect_to :action => "index"
    return
  end
  if user.vip?
    redirect_to :action => "vip_lounge", :id => params[:id]
    # forgot return
  end
  if user.long_distance?
    redirect_to :action => "long_distance", id => params[:id]
    # line above will BOOM for vip, long_distance user
    return
  end
end

and there you have it ... I forgot 1 return ... A user that is vip? and
intercontinental? will cause an exception (and even if I tested each
separate use case, I may have forgotten to test this _combination_ ...).

Also, duplicating the "return" after each redirect_to or render
seems not DRY.

At one point, I was grepping my code for each "redirect_to",
"render" to see if I had written a return after it ...

A solution ?

Would this be a good use case for Catch / Throw ?

Then the Web Framework  call to User#show could be
wrapped in a catch block like

class WebFramework
...
  catch :render_or_redirect do
    User.show
  end

end

and then we defined a function

def redirect_to_with_throw(*arguments)
  redirect_to(*arguments)
  throw :render_or_redirect
end

which can be used in the controller as:

def show
  user = User.find(params[:id])
  if user.secret?
    flash[:warning] = "sorry, this is secret"
    redirect_to_with_throw :action => "index"
  end
...

That might be a nice extension to the web framework,
to catch a :render_or_redirect throw. If I understand
correctly, the catch in the framework would not
hinder the existing code or developers not using
the feature (that is, never throwing :render_or_redirect).

HTH,

Peter

In This Thread