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
and even
foo do
bar
rescue
baz
ensure
bur
end
These would be equivalent to
foo do
begin
bar
rescue
baz
ensure
bur
end
end
When an ensure clause is added, the expression evaluated therein will always be the return value of a call to the block -- just as if there was a begin/end block inside the do/end block.
This wouldn't offer any new functionality, but would make the use of rescue and ensure clauses more consistent -- currently they work with begin, class, and def blocks (more?).
There's of course the case of the curly bracket block syntax, but I see no need to support it there -- I think it's most commonly used with one-liners, where rescuing may be overkill.
I'd like some feedback, and if its generally positive, I'll post an RCR.
Cheers,
Daniel
I've tried that syntax myself and been surprised when it failed. It seems
like less typing to me- usually a good thing!
Justin
···
On 5/18/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> 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.
Just playing Devil's Advocate, what'd happen with this:
File.open('somefile') do |f|
puts f.read
end rescue puts "Can't open"
?
···
On Thu, 2006-05-18 at 23:55 +0900, 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
--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk
The main reason that Matz has opposed it before is:
foo {
bar
rescue
baz
}
It does look odd, but I think people will just get used to it.
-austin
···
On 5/18/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> 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.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
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.
···
On May 18, 2006, at 7:55 AM, Daniel Schierbeck wrote:
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
Ross Bamford 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
Just playing Devil's Advocate, what'd happen with this:
File.open('somefile') do |f|
puts f.read
end rescue puts "Can't open"
The same as there would now; since the rescue clause is not inside the do/end block, it is not affected by this proposal.
The difference would be that your version would also rescue exceptions raised by File.open, while the proposed syntax would only rescue exceptions raised within the block given to File.open.
But I like the devil's advocate approach, it makes the proposals sharper 
Daniel
···
On Thu, 2006-05-18 at 23:55 +0900, Daniel Schierbeck wrote:
Eric Hodel wrote:
Setting up and tearing down an exception handler for every block
invocation is going to be expensive.
Couldn't the setup/teardown be done only if a rescue/ensure clause was
actually present? It also seems to me that this would mean the the
setup/teardown would have to be in the block itself, not in the calling
method. Thus making it hard to rescue exceptions from the calling
method (as some have suggested).
For the record,
(A) if it can be done efficiently, I'm for it.
(B) I'm not in favor of rescuing exceptions from the parent method.
That just seems backwards to me.
···
--
-- Jim Weirich
--
Posted via http://www.ruby-forum.com/\.
Austin Ziegler wrote:
The main reason that Matz has opposed it before is:
foo {
bar
rescue
baz
}
It does look odd, but I think people will just get used to it.
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.
Daniel
Eric Hodel wrote:
Setting up and tearing down an exception handler for every block invocation is going to be expensive.
I vote no.
Wouldn't it be possible to only set up an exception handler for blocks that actually have rescue clauses?
Daniel
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?
Daniel
Ross Bamford 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
>
> Just playing Devil's Advocate, what'd happen with this:
>
> File.open('somefile') do |f|
> puts f.read
> end rescue puts "Can't open"
The same as there would now; since the rescue clause is not inside the
do/end block, it is not affected by this proposal.
The difference would be that your version would also rescue exceptions
raised by File.open, while the proposed syntax would only rescue
exceptions raised within the block given to File.open.
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
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).
···
On Fri, 2006-05-19 at 00:34 +0900, Daniel Schierbeck wrote:
> On Thu, 2006-05-18 at 23:55 +0900, Daniel Schierbeck wrote:
--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk
uncutstone wu wrote:
Ross Bamford 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
Just playing Devil's Advocate, what'd happen with this:
File.open('somefile') do |f|
puts f.read
end rescue puts "Can't open"
?
What if rescue has more than one sentence? It seems not a good idea.
But I agree with Daniel Schierbeck's proposal.
I think the syntax would be changed as below:
File.open('somefile') do |f|
puts f.read
rescue
puts "Can't open"
end
···
On Thu, 2006-05-18 at 23:55 +0900, Daniel Schierbeck wrote:
--
Posted via http://www.ruby-forum.com/\.
Not true. do/end and {/} are interchangeable except you may need to add () for precedence.
···
On May 18, 2006, at 12:58 PM, Daniel Schierbeck wrote:
Austin Ziegler wrote:
The main reason that Matz has opposed it before is:
foo {
bar
rescue
baz
}
It does look odd, but I think people will just get used to it.
I think it looks too odd. The do/end and the curly bracket syntaxes are used in different places
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
I forgot that the parser will just take care of it. The patch was easy, applies to a recentish copy of the 1.8 branch:
do-rescue.patch (944 Bytes)
···
On May 18, 2006, at 11:22 AM, Jim Weirich wrote:
Eric Hodel wrote:
Setting up and tearing down an exception handler for every block
invocation is going to be expensive.
Couldn't the setup/teardown be done only if a rescue/ensure clause was
actually present? It also seems to me that this would mean the the
setup/teardown would have to be in the block itself, not in the calling
method.
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.
-austin
···
On 5/18/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:
Austin Ziegler wrote:
> The main reason that Matz has opposed it before is:
>
> foo {
> bar
> rescue
> baz
> }
>
> It does look odd, but I think people will just get used to it.
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.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca