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.
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
I think it looks too odd. The do/end and the curly bracket syntaxes are
used in different places – if I needed error handling, I would never
use the curly brackets anyway. I see the problem, though; I just don’t
think it’s big enough to block the implementation of this.
No, they’re not used in different places, not really.
I know some people use {} for one-liners and do/end for
multiple-liners, but sometimes it is important to use one over the
other because of the binding precedence.
foo bar {} # the block binds with bar
foo bar do end # the block binds with foo
If you’re going to have it for do/end, you need it for {}, too.
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:
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.
Maybe it’s time we make that distinction. From a syntactical
point of view, they’re very different
parse.y disagrees with you.
That’s implementation. We ought to be able to abstract away from
that, right? Isn’t Ruby about the programmer, not the computer?
No, ruby itself directly contradicts you. The language defines only
one difference between {/} and do/end, precedence. Increasing the
differences will make ruby more about the computer than the
programmer because you must remember what to put where to please the
interpreter. Adding syntax is usually makes the language more
complicated and that can only be bad.
view, they’re very different
parse.y disagrees with you.
That’s implementation. We ought to be able to abstract away from that,
right? Isn’t Ruby about the programmer, not the computer?
Yes, but as I said – and I know you haven’t seen it as I’m writing it
– Ruby treats them exactly the same except for precedence. I like it
that way, personally.
|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?
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.
In message “Re: Rescue clauses on do/end blocks?”
on Fri, 19 May 2006 01:26:09 +0900, uncutstone wu [email protected] 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.
In message “Re: Rescue clauses on do/end blocks?”
on Fri, 19 May 2006 09:07:49 +0900, “Austin Z.” [email protected] writes:
|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.
If (a) is the case, the value from the rescue clause is used for a
block value when an exception happens. The value from the ensure
clause is ignored always.
(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.
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.
| end
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.
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).
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.
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).
I’m on the same page as Robert – I didn’t even think of rescuing
exceptions raised by the method before someone here mentioned it.
Besides, Ruby’s exception handling differs pretty much from other
languages, in that you can put rescue clauses on class and method
definitions.
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.
I misremembered what AST would be built. The setup only occurs when
there is a rescue clause.
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.
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?
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.
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.
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?
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.
Do we really need to allow rescue clauses
on curly bracket blocks?
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.
