I misremembered what AST would be built. The setup only occurs when there is a rescue clause.
···
On May 18, 2006, at 5:29 PM, Hal Fulton wrote:
Eric Hodel wrote:
On May 18, 2006, at 7:55 AM, Daniel Schierbeck wrote:
I know this has been on the table before, but I really see no reason not to allow do/end blocks to have rescue clauses on them, i.e.
foo do
bar
rescue
baz
end
[...]
I'd like some feedback, and if its generally positive, I'll post an RCR.
Setting up and tearing down an exception handler for every block invocation is going to be expensive.
I vote no.
I guess I assumed that it would only do the setup if the rescue
clause actually appeared. But I don't know how the parser and
such really work.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
Okay, if this proposal is blocked by the lack of an elegant way to add
clauses to curly bracket blocks, let's be proactive (hehe) and see if we
can't come up with one.
I don't think that it's elegant or inelegant. It's just something that
looks odd. I personally want it.
Off the top of my head, I thought of this:
foo {
bar
} rescue {
baz
} ensure {
bur
}
which is a bit like in PHP, if I remember correctly.
a) Would this be implementable?
b) Would this be a tolerable syntax for y'all?
It might be implementable, but I find it intolerable.
-austin
···
On 5/19/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Ross Bamford wrote:
Does that mean that with the proposed syntax, to rescue an exception
from this File.open, we'd have to use:
begin
File.open('somefile') do |f|
puts f.read
rescue
# exception from f.read
end rescue
# exception from File.open
end
As I imagine it right now, rescue clauses on do/end blocks would only rescue exceptions raised *inside* that block -- to rescue exceptions raised with the method the block is attached to, one must wrap the method with begin/end.
But I like the devil's advocate approach, it makes the proposals sharper 
In truth, I think I'm in favour of this change, especially if it
could be done so that the rescue catches exceptions from the block _as
well_ as those from the method to which the block is attached (if any).
I'm not sure I'd like that -- I see a block attached to a method call as being, in some sense, a child of that call, another kind of argument if you will; having the child rescue exceptions raised by the parent seems unintuitive to me, though others may feel different.
People, feel free to chime in.
Daniel
uncutstone wu wrote:
I think the syntax would be changed as below:
File.open('somefile') do |f|
puts f.read
rescue
puts "Can't open"
end
Rather:
File.open('pr0n') do |f|
puts f.read
rescue
puts "can't read"
end
since we won't rescue any exceptions raised by File.open, only those raised by File#read.
Daniel
dblack@wobblini.net wrote:
I'm not sure I get that distinction -- I mean, I understand that you
do it that way, but I'm not sure there's any generally closer
association between do/end and rescuing than there is between {} and
rescuing. Also, they're sometimes used in the *same* places, but by
different people
Maybe it's time we make that distinction. From a syntactical point of view, they're very different -- only the keyword/end syntax really allows for such things as if/elsif/else/end and rescue clauses, unless you want to add this to Ruby:
proc { foo } rescue { bar } ensure { baz }
Which in my opinion is just too verbose.
I like the curly syntax as a shorthand, but I don't think we need it to support all the same things the more "flexible" do/end syntax does.
Daniel
Hi,
I think the syntax would be changed as below:
File.open('somefile') do |f|
puts f.read
rescue
puts "Can't open"
end
Which do you expect from above code?
(a)
File.open('somefile') do |f|
begin
puts f.read
rescue
puts "Can't open"
end
end
(b)
begin
File.open('somefile') do |f|
puts f.read
end
rescue
puts "Can't open"
end
It's naturally (a) from my point of view, since I know how blocks work
internally. But as you did, many might expect (b). This ambiguity
may become serious disadvantage.
matz.
···
In message "Re: Rescue clauses on do/end blocks?" on Fri, 19 May 2006 01:26:09 +0900, uncutstone wu <uncutstone@sina.com> writes:
No. You still decide where to catch the exception. You can do it
inside the block or outside. It's just a syntactical change which
obsoletes a pair of begin end inside the block.
Kind regards
robert
···
2006/5/18, Ross Bamford <rossrt@roscopeco.co.uk>:
Does that mean that with the proposed syntax, to rescue an exception
from this File.open, we'd have to use:
begin
File.open('somefile') do |f|
puts f.read
rescue
# exception from f.read
end
rescue
# exception from File.open
end
--
Have a look: Robert K. | Flickr
Daniel Schierbeck wrote:
In truth, I think I'm in favour of this change, especially if it
could be done so that the rescue catches exceptions from the block _as
well_ as those from the method to which the block is attached (if any).
I'm not sure I'd like that -- I see a block attached to a method call as
being, in some sense, a child of that call, another kind of argument if
you will; having the child rescue exceptions raised by the parent seems
unintuitive to me, though others may feel different.
I agree with Daniel. It should only rescue exceptions raised in the
block, not the parent/holder/caller/receiver of the block.
Pistos
···
--
Posted via http://www.ruby-forum.com/\.
parse.y disagrees with you.
···
On May 18, 2006, at 2:24 PM, Daniel Schierbeck wrote:
dblack@wobblini.net wrote:
I'm not sure I get that distinction -- I mean, I understand that you
do it that way, but I'm not sure there's any generally closer
association between do/end and rescuing than there is between {} and
rescuing. Also, they're sometimes used in the *same* places, but by
different people
Maybe it's time we make that distinction. From a syntactical point of view, they're very different
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
Blocks are blocks. Stylistically, some people prefer braces, some
people prefer do/end. There are people who will do everything they can
to make sure that they always use the same style. There are people who
use {} for blocks that return a value (and the exception handler is
*very* important there) and do/end for those that don't. There are
people who use {} for one-liners and do/end for multi-liners.
The curly syntax is *not* just a shorthand. It has a different binding.
-austin
···
On 5/18/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:
dblack@wobblini.net wrote:
> I'm not sure I get that distinction -- I mean, I understand that you
> do it that way, but I'm not sure there's any generally closer
> association between do/end and rescuing than there is between {} and
> rescuing. Also, they're sometimes used in the *same* places, but by
> different people
Maybe it's time we make that distinction. From a syntactical point of
view, they're very different -- only the keyword/end syntax really
allows for such things as if/elsif/else/end and rescue clauses, unless
you want to add this to Ruby:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
I expect (a), personally. The only thing that could confuse it is the
bit about returning or breaking from a block/proc that I *still* don't
quite understand.
-austin
···
On 5/18/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
>I think the syntax would be changed as below:
> File.open('somefile') do |f|
> puts f.read
> rescue
> puts "Can't open"
> end
Which do you expect from above code?
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Yukihiro Matsumoto wrote:
(a)
File.open('somefile') do |f|
begin
puts f.read
rescue
puts "Can't open"
end
end
(b)
begin
File.open('somefile') do |f|
puts f.read
end
rescue
puts "Can't open"
end
It's naturally (a) from my point of view, since I know how blocks work
internally. But as you did, many might expect (b). This ambiguity
may become serious disadvantage.
I expect case a. Sorry I didn't carefully check the code I gave, "Can't
open " should be " Can't read". That made the ambiguity.
···
--
Posted via http://www.ruby-forum.com/\.
Hm, I beg to differ: the "rescue" is *inside* the block so it can
catch only exceptions raised from within the block. I for my part
would find it rather strange to expect that you can catch an exception
that was thrown because of problems opening the file. So my natural
expectation would be (a).
Kind regards
robert
···
2006/5/19, Yukihiro Matsumoto <matz@ruby-lang.org>:
Hi,
In message "Re: Rescue clauses on do/end blocks?" > on Fri, 19 May 2006 01:26:09 +0900, uncutstone wu <uncutstone@sina.com> writes:
>I think the syntax would be changed as below:
> File.open('somefile') do |f|
> puts f.read
> rescue
> puts "Can't open"
> end
Which do you expect from above code?
(a)
File.open('somefile') do |f|
begin
puts f.read
rescue
puts "Can't open"
end
end
(b)
begin
File.open('somefile') do |f|
puts f.read
end
rescue
puts "Can't open"
end
It's naturally (a) from my point of view, since I know how blocks work
internally. But as you did, many might expect (b). This ambiguity
may become serious disadvantage.
--
Have a look: Robert K. | Flickr
Eric Hodel wrote:
foo {
bar
} rescue {
baz
} ensure {
bur
}
I find it intolerable.
Agreed.
I don't think it's pretty, either. But you seem very keen on destroying this proposal -- you say you need a way to add rescue clauses to curly bracket blocks, and when I present one, you just dismiss it.
I'd like you to be more constructive here.
1. Do we *really* need to allow rescue clauses
on curly bracket blocks?
2. If yes, what syntax would you propose?
Personally, I don't think we need it. Curly brackets don't look like begin/end, class/end, or def/end at all; do/end does. I've tried adding a rescue clause to a do/end block, expecting it to work, I've never done that with curly brackets blocks.
Daniel
Austin Ziegler wrote:
Blocks are blocks. Stylistically, some people prefer braces, some
people prefer do/end. There are people who will do everything they can
to make sure that they always use the same style. There are people who
use {} for blocks that return a value (and the exception handler is
*very* important there) and do/end for those that don't. There are
people who use {} for one-liners and do/end for multi-liners.
The curly syntax is *not* just a shorthand. It has a different binding.
Personally, I wouldn't mind a distinction between the two. Maybe an official convention?
Daniel
Eric Hodel wrote:
foo {
bar
} rescue {
baz
} ensure {
bur
}
I find it intolerable.
Agreed.
I don't think it's pretty, either. But you seem very keen on destroying this proposal
I've been using Ruby for a long time, and I can count on my two hands the number of times I've placed a begin inside a block. This makes my highly skeptical of your need for it.
If you read through the mailing list you'll find all syntax change proposals meet this kind of treatment.
-- you say you need a way to add rescue clauses to curly bracket blocks, and when I present one, you just dismiss it.
Probably because we don't think it is rubyish. Note that this has been proposed before and nobody's come up with a good-enough solution yet.
Here's what I see as the problems with your proposal:
You omitted how you would specify which exceptions would be rescued.
} else { would be very confusing.
Your current solution looks entirely unlike ruby's current exception catching syntax.
Your current solution looks entirely unlike any current ruby code.
···
On May 19, 2006, at 10:26 AM, Daniel Schierbeck wrote:
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com