From: Rick DeNatale <rick.denatale@...>
Date: 2006-09-14T08:23:24+09:00
Subject: Re: Struggling with Blocks

On 9/13/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>
> On Sep 12, 2006, at 12:39 PM, Rick DeNatale wrote:
> > Now there might be a reason why the do..end, or {..} of a block can't
> > have the same feature, but I'm scratching my head to figure out why.
> > You CAN have a block which contains a single statement with a rescue
> > modifier:
> >
> >    lambda do
> >         raise "help!" rescue "gotcha"
> >    end
> >
> > is legal as is the semantically equivalent:
> >
> >   lambda {raise "help!" rescue "gotcha"}
>
>
> These two example illustrate the ability to attach a rescue modifier
> to a method call.
> The fact that in these example the method calls are sitting by
> themselves inside
> a block is irrelevant--the rescue is associated with the call and not
> with
> the enclosing block.

Yes, I knew all that.  I was trying to think of a semantic reason to
require wrapping exception handlers in a block inside a proc, when I
realized that a statement modifer gave some capability to do this as a
kind of degenerate case. The fact that you can have a block with a
single statement with a rescue modifier seems to weaken any argument
that you shouldn't be able to say

x.each do |a|
     statement 1
     statement 2
     rescue
         rescue-statement
     end

when you can say

   def meth(a)
         statement-1
         statement-2
         rescue
             rescue-statement
    end

It seems to be a purely syntactic restriction, with no semantic necessity.

I just searched RCRchive, and there's an existing RCR336 advocating
allowing rescue's in do..end blocks without requiring begin..end
inside.  It seems like a good change to me, so I just voted for it.

But then I could be wrong.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/