From: Robert Dober <robert.dober@...>
Date: 2007-07-20T19:29:37+09:00
Subject: Re: RCR? Added syntax for chains that possibly return nil

On 7/20/07, Trans <transfire@gmail.com> wrote:
>
>
> On Jul 19, 4:34 pm, Stefan Rusterholz <apei...@gmx.net> wrote:
> > Trans wrote:
> > > On Jul 19, 3:33 pm, Stefan Rusterholz <apei...@gmx.net> wrote:
> > >> Trans wrote:
> > >> > what about
> > >> >   foo = bar.baz.quuz rescue default
> >
> > >> See the answer to gabriele renzi (Simple: what if your exception is not
> > >> the NoMethodError you are worried
> > >> about? You'll never know.)
> >
> > > I think it rescues all StandardErrors.
> >
> > > T.
> >
> > Um, Yes, that's exactly the problem about it, wasn't that clear? It
> > rescues *all* StandardErrors. So you won't notice if something else than
> > your NoMethodError - which nil would raise - has happened.
> > Say your gets raises a BrokenPipe exception or similar since the server
> > you were connected disconnects you because of bad input you send. Your
> > will never see an exception being raised since that happens in the gets
> > you just rescue all standarderrors from.
>
> So a better RCR maybe it just to qualify the line rescue.
> NoMethodError being the more common, maybe a special rescue for that.
> Eg.
>
>   bar.baz.quuz ||| default
Hmm I like the expressiveness of the original proposal
look at this example

   bar->baz.foo, which has to be written as
   (bar.baz ||| default).foo

of course one could write
   bar.baz.foo ||| default
but it has more permissive semantics and will hide errors that
  bar->baz.foo
will raise
Robert


-- 
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck