rescue inside block -> syntax error

[Simon Strandgaard]

While reading this message:
http://groups.google.dk/[email protected]


What is the reason that this isn't possible ?

And what happened to the RCR?

server> ruby a.rb
a.rb:3: syntax error
server> expand -t2 a.rb
loop do
raise 666
rescue
puts "rescue"
raise # re-raise
end
server>

 

[Chris Pine]

Maybe I'm not understanding what you are getting at, but:

irb(main):001:0> loop do
irb(main):002:1* begin
irb(main):003:2* raise 666
irb(main):004:2> rescue
irb(main):005:2> puts "rescue"
irb(main):006:2> raise
irb(main):007:2> end
irb(main):008:1> end
rescue
TypeError: exception class/object expected
from (irb):3:in `raise'
from (irb):3
from (irb):1:in `loop'
from (irb):8


Seems to work fine... if you get the syntax right! As I understand it,
"begin...rescue...end" is the construct, just like "class...end" or
"def...end". None of these are blocks, though, just different language
constructs.

Or perhaps you meant something I am missing?

Chris

 

[Simon Strandgaard]

Maybe I'm not understanding what you are getting at, but: [snip]
Or perhaps you meant something I am missing?

Sorry if it wasn't clear.. I wanted to express that it would
be really nice if 'rescue' and 'ensure' could be used within
do..end blocks.

wrapping things in begin..end feels superfluous ;-)

 

[gabriele renzi]

il Thu, 04 Mar 2004 16:00:16 +0100, Simon Strandgaard

Maybe I'm not understanding what you are getting at, but: [snip]
Or perhaps you meant something I am missing?

Sorry if it wasn't clear.. I wanted to express that it would
be really nice if 'rescue' and 'ensure' could be used within
do..end blocks.

wrapping things in begin..end feels superfluous ;-)

+1, and IIRC that rcr just felt in some limbo.. What was wrong with it
?

 

[Kent Dahl]

il Thu, 04 Mar 2004 16:00:16 +0100, Simon Strandgaard



+1, and IIRC that rcr just felt in some limbo.. What was wrong with it
?

For starters, it would start drifting do..end blocks and {..} blocks
apart, unless you'd allow it in those too.

{|this|
this.will
ensure
self.gag
other_who_like_curly_braces.gag
}

 

[Hal Fulton]

For starters, it would start drifting do..end blocks and {..} blocks
apart, unless you'd allow it in those too.

{|this|
this.will
ensure
self.gag
other_who_like_curly_braces.gag
}

Personally, I wouldn't mind this. I only use {} on single lines
(as many do).

They already look very different. Why not let them behave as
differently as they look?

I do think the "generic rescue" might impose a little extra work
(a lot?) on the interpreter.

For example, when we see "begin" we know there's a good chance
we'll be seeing a "rescue." Once this is changed: When we see "do"
we're not sure whether to expect a rescue or not. Couldn't this
impact code generation (interpreting in this case) as well as
parsing? (Disclaimer: I know little about interpreters.)

Hal

 

[Gavin Sinclair]

il Thu, 04 Mar 2004 16:00:16 +0100, Simon Strandgaard
<[email protected]> ha scritto::

Maybe I'm not understanding what you are getting at, but: [snip]
Or perhaps you meant something I am missing?

Sorry if it wasn't clear.. I wanted to express that it would
be really nice if 'rescue' and 'ensure' could be used within
do..end blocks.

wrapping things in begin..end feels superfluous ;-)

+1, and IIRC that rcr just felt in some limbo.. What was wrong with it
?

+10 for me! The RCR probably needs to be resubmitted in the new
format.

Cheers,
Gavin

 

[Gavin Sinclair]

For starters, it would start drifting do..end blocks and {..} blocks
apart, unless you'd allow it in those too.

{|this|
this.will
ensure
self.gag
other_who_like_curly_braces.gag
}

But what is the alternative? I mean, how often do you see code like
this?

meth(arg) {
begin
# ...
rescue
# ...
end
}

Gavin

 

[Robert Klemme]

But what is the alternative? I mean, how often do you see code like
this?

meth(arg) {
begin
# ...
rescue
# ...
end
}

Rarely enough, true.

There's an issue that limits the usability of do..ensure..end: Typically
you do resource allocation *outside* the begin..end because you don't want
the ensure clause to be executed if something during init fails:

container.each do |obj|
processor = create_processor_in_a_way_that_might_throw()

begin
processor.do_work()
processor.do_more_work()
ensure
processor.cleanup()
end
end

or

def File.open(file, mode="r")
io = create_io_and_throw_if_not_found(file)

begin
yield io
ensure
io.close()
end
end

In all these cases you don't gain anything by having do..ensure..end.

Kind regards

robert

 

[Joe Mason]

There's an issue that limits the usability of do..ensure..end: Typically
you do resource allocation *outside* the begin..end because you don't want
the ensure clause to be executed if something during init fails:

container.each do |obj|
processor = create_processor_in_a_way_that_might_throw()

begin
processor.do_work()
processor.do_more_work()
ensure
processor.cleanup()
end
end

But wouldn't the ruby way be to write this?

container.each do |obj|
processor.create_in_a_way_that_might_throw do |proc|
proc.do_work()
proc.do_more_work()
ensure
proc.cleanup()
end
end

Joe

 

[Robert Klemme]

But wouldn't the ruby way be to write this?

No, because that would duplicate cleanup code.

container.each do |obj|
processor.create_in_a_way_that_might_throw do |proc|

I gues you rather mean

ProcessorClass.create_in_a_way_that_might_throw do |proc|

proc.do_work()
proc.do_more_work()
ensure
proc.cleanup()

The cleanup wrong here because it is done in method
create_in_a_way_that_might_throw() in this scheme after the yield (see
File.open() and below).

end
end

Joe

And how then will you implement create_in_a_way_that_might_throw()?
That's the second example I gave - slightly changed to fit the naming:

def create_in_a_way_that_might_throw()
# initialization, might throw
processor = ...

begin
yield processor
ensure
processor.cleanup()
end
end

Regards

robert

 

[Joe Mason]

No, because that would duplicate cleanup code.


I gues you rather mean

ProcessorClass.create_in_a_way_that_might_throw do |proc|
Right.


The cleanup wrong here because it is done in method
create_in_a_way_that_might_throw() in this scheme after the yield (see
File.open() and below).

Oh, that's an ensure, not an except. I was reading too fast (and I
still find Ruby's exception keywords hard to sort out, since they're so
different from everything else I've used.

Still, I think my example would be a good way to write a rescue clause
for actions only taken in case of failure, and which would benefit from
being able to put rescue in arbitrary blocks.

Joe

 

[Robert Klemme]

Oh, that's an ensure, not an except. I was reading too fast (and I
still find Ruby's exception keywords hard to sort out, since they're so
different from everything else I've used.

Still, I think my example would be a good way to write a rescue clause
for actions only taken in case of failure, and which would benefit from
being able to put rescue in arbitrary blocks.

Yeah, it sounds more reasonable for rescue clauses than ensure clauses.
Agreed.

Regards

robert

 

[Simon Strandgaard]

il Thu, 04 Mar 2004 16:00:16 +0100, Simon Strandgaard

[snip]
Or perhaps you meant something I am missing?


Sorry if it wasn't clear.. I wanted to express that it would
be really nice if 'rescue' and 'ensure' could be used within
do..end blocks.

wrapping things in begin..end feels superfluous ;-)

+1, and IIRC that rcr just felt in some limbo.. What was wrong with it
?

+10 for me! The RCR probably needs to be resubmitted in the new
format.

I located the lost RCR... its
RCR 105: Change do...end to support exception handling
http://rcrchive.net/rgarchive/rejected.html

matz rejected it for the reason:
rescue etc in "do .. end" seem weird when a block consists a loop.



Still I think its a great RCR. +8 here ;-)