Forum: Ruby Rescuing blocks?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Daniel N. (Guest)
on 2006-02-12 20:27
(Received via mailing list)
Hey guys,

I was working on a DSL for some asynchronous programming stuff and I
realized it'd be really nice if a block could rescue an exception.

So I went into IRB to see if it works and got a parse error.  I
suppose you need a begin... end block or a proper method to have a
rescue block right now.

I was wondering if there's any reason why this is so?  It'd seem
pretty natural to me that a block could have rescue/else/ensure
conditions since a method body can have them.

Has this been discussed elsewhere?

Thanks,
David V. (Guest)
on 2006-02-12 20:44
(Received via mailing list)
DÅ?a Nedeľa 12 Február 2006 19:26 Daniel N. napísal:
> pretty natural to me that a block could have rescue/else/ensure
> conditions since a method body can have them.
>
> Has this been discussed elsewhere?
>
> Thanks,
>
> --
> -Dan Nugent

I'm afraid I don't quite catch your drift. What do you mean by a block
not
rescuing an exception? Some example code wouldn't hurt.

David V.
Daniel N. (Guest)
on 2006-02-12 20:56
(Received via mailing list)
Whoops, shoulda thought of that, a-doy.

Okay, it's pretty simple, here's what I'd like to do (you can
extrapolate the rest of the syntax from the simple example):

foo = [1, 2, 3]

foo.each do |o|
  raise "Oh noes, it's number 2!" if o == 2
rescue Exception => e
  puts e.to_s
end

And so on and so forth.  It seems pretty natural to me.... I don't
think it breaks anything (least not off the top of my head)...
Lou V. (Guest)
on 2006-02-12 21:10
(Received via mailing list)
this works,

foo = [1, 2, 3]

foo.each do |o|
	begin
	  raise "Oh noes, it's number 2!" if o == 2
	rescue Exception => e
	  puts e.to_s
	end
end
Mark V. (Guest)
on 2006-02-12 21:39
(Received via mailing list)
On 2/12/06, Lou V. <removed_email_address@domain.invalid> wrote:
> end
Sure it works, but Daniel wants to reduce the syntax a bit AND exit
the loop if an exception is raised without having to specify that. I
like his suggestion.
David V. (Guest)
on 2006-02-12 22:24
(Received via mailing list)
DÅ?a Nedeľa 12 Február 2006 20:39 Mark V. napísal:
> >         end
> > end
>
> Sure it works, but Daniel wants to reduce the syntax a bit AND exit
> the loop if an exception is raised without having to specify that. I
> like his suggestion.
>
> --
> R. Mark V.
> Partner, Object Computing, Inc.

It would cause a little inconsistency with the curly brace form of
blocks.
Either the rescue clause would have to work only for the do / end form,
or
we'd be mixing braces and keywords in a single construct, which I
couldn't
bear to look at.

David V.
Daniel N. (Guest)
on 2006-02-12 22:44
(Received via mailing list)
Is

foo.each {|o|
  raise "Oh noes, it's number 2!" if o == 2
rescue Exception => e
    puts e.to_s
}

really that hideous?
David V. (Guest)
on 2006-02-12 23:27
(Received via mailing list)
How would you parse the difference whether the raise applies to the
whole
block, or just the previous statement?

David V.

Dòa Nedeµa 12 Február 2006 21:43 Daniel N. napísal:
Daniel N. (Guest)
on 2006-02-12 23:46
(Received via mailing list)
Sorry, not sure what the issue is (I assume you mean rescue, not raise
there).

If a rescue appears after a statement, it only applies to that
statement.  If a rescue appears as the first token on a line, it
applies to the enclosing block.  I'm pretty sure that's how it works
now.

If you're talking about doing something like...

foo.each{|o| raise "Oh noes, it's number 2!" if o == 2; rescue
Exception => e; puts e.to_s}

It's still obvious how it works.
David V. (Guest)
on 2006-02-13 00:10
(Received via mailing list)
Dòa Nedeµa 12 Február 2006 22:46 Daniel N. napísal:
> Sorry, not sure what the issue is (I assume you mean rescue, not raise
> there).
>
> If a rescue appears after a statement, it only applies to that
> statement.  If a rescue appears as the first token on a line, it
> applies to the enclosing block.  I'm pretty sure that's how it works
> now.

<dense>D'oh. Didn't know that one... </dense>


David V.
Patrick H. (Guest)
on 2006-02-13 18:20
(Received via mailing list)
On 2/12/06, David V. <removed_email_address@domain.invalid> wrote:
>
> <dense>D'oh. Didn't know that one... </dense>
>
>
> David V.
>
>

+1
Daniel N. (Guest)
on 2006-02-13 21:30
(Received via mailing list)
So, maybe this calls for a RCR?

I know for sure that I'd like blocks to be rescuable.
David V. (Guest)
on 2006-02-14 23:29
(Received via mailing list)
Dòa Pondelok 13 Február 2006 17:20 Patrick H. napísal:
> +1
>

Die.

David V.
Allergic to anything remotely resembling slashdot
Eric H. (Guest)
on 2006-02-15 00:36
(Received via mailing list)
On Feb 12, 2006, at 10:55 AM, Daniel N. wrote:

>   puts e.to_s
> end
>
> And so on and so forth.  It seems pretty natural to me.... I don't
> think it breaks anything (least not off the top of my head)...

You're going to get a performance hit setting up an exception trap
this way.

--
Eric H. - removed_email_address@domain.invalid - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Dave C. (Guest)
on 2006-02-15 05:53
(Received via mailing list)
Eric H. wrote:
>
> You're going to get a performance hit setting up an exception trap this
> way.

Time for some down-South edumucation. What kind of performance hit are
we talking about here? And why the hit at all?

(I seem to recall reading somewhere once upon a time about memory stack
stuff, but I'm not an old-school C-programmer so I never had to deal
with it --- unfortunately for me...)

-dave
Hal F. (Guest)
on 2006-02-15 07:51
(Received via mailing list)
Dave C. wrote:
> stuff, but I'm not an old-school C-programmer so I never had to deal
> with it --- unfortunately for me...)

Well, my knowledge is limited. Someone else can answer better.

But look at it from a common-sense standpoint. Exceptions aren't
magic. Everything Ruby does can be done in assembly language, it's
just more verbose.

I would think that exceptions, at the lowest level, work something
like:

    if something_happened_here
       goto the_place_where_exceptions_are_caught

So at the very least, catching exceptions means that you're doing
some sort of comparison or conditional branch. And this is code
that doesn't have to be run/generated *unless* you are catching
exceptions.

Just my naive take.


Hal
Dave C. (Guest)
on 2006-02-15 08:06
(Received via mailing list)
Hal F. wrote:
>> (I seem to recall reading somewhere once upon a time about memory
> like:
>
>
> Hal
>
>
>

That's kind of along the lines of what I was thinking, just better said.
But this makes me wonder:

(a) Worrying about the performance hit from comparison/conditional
branching leads to the question "is all branching in blocks bad?"
Obviously not.

(b) Couldn't you say that *any* conditional could be jumping out to
another section of code? i.e. not just exception handlers?

   if this_is_true
      goto where_we_do_stuff_when_this_is_true

Hmm. This is something I've read, and it's in my brain somewhere, but I
don't know it well enough to grok it yet.

Especially at midnight... :(

But your explanation gives me a better idea of what is happening, even
with my questions.

Thanks!
-dave
Hal F. (Guest)
on 2006-02-15 08:18
(Received via mailing list)
Dave C. wrote:
>>>
>> But look at it from a common-sense standpoint. Exceptions aren't
>> some sort of comparison or conditional branch. And this is code
>
>   if this_is_true
>      goto where_we_do_stuff_when_this_is_true
>
> Hmm. This is something I've read, and it's in my brain somewhere, but I
> don't know it well enough to grok it yet.
>
> Especially at midnight... :(
>
> But your explanation gives me a better idea of what is happening, even
> with my questions.

Well, I think the point is that there is some non-zero amount of
"invisible"
code inserted between each statement. In fact, at a higher level of
granularity
than the statement.

For example, if I say:  x = a/(b/(c/d))   there are three possible
places that
a ZeroDivision exception (or whatever it's called) might happen.
Mentally, I'm
envisioning if-statements sprinkled throughout the evaluation of the
expression.
But again, this is all naive talk.


Hal
Eric H. (Guest)
on 2006-02-15 10:55
(Received via mailing list)
On Feb 14, 2006, at 9:50 PM, Hal F. wrote:

>
>       goto the_place_where_exceptions_are_caught
>
> So at the very least, catching exceptions means that you're doing
> some sort of comparison or conditional branch. And this is code
> that doesn't have to be run/generated *unless* you are catching
> exceptions.

Yes.  You get a setup/teardown of an exception handler for every
block.  Right now class module and def have an implicit exception
handler built in.  Adding a begin; rescue; end explicitly to blocks
gives you a very hefty penalty.  That's no guarantee of similarly bad
performance with an implicit exception handler, but it still won't be
free.

I've very rarely found myself placing an exception handler directly
inside a block so I don't think it would be worth it.

$ cat rescue.rb
require 'benchmark'

N = 10_000_000

Benchmark.bmbm do |b|
   b.report 'begin' do
     N.times { begin; rescue; end }
   end

   b.report 'no begin' do
     N.times { }
   end
end

$ ruby -v rescue.rb
ruby 1.8.4 (2005-12-24) [powerpc-darwin8.4.0]
Rehearsal --------------------------------------------
begin      6.330000   0.060000   6.390000 (  8.303914)
no begin   2.580000   0.010000   2.590000 (  3.178967)
----------------------------------- total: 8.980000sec

                user     system      total        real
begin      6.320000   0.060000   6.380000 (  8.597418)
no begin   2.570000   0.020000   2.590000 (  3.526030)

--
Eric H. - removed_email_address@domain.invalid - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Patrick H. (Guest)
on 2006-02-15 13:29
(Received via mailing list)
On 2/15/06, Eric H. <removed_email_address@domain.invalid> wrote:
> >> stack stuff, but I'm not an old-school C-programmer so I never had
> >
> handler built in.  Adding a begin; rescue; end explicitly to blocks
> N = 10_000_000
>
>
> --
> Eric H. - removed_email_address@domain.invalid - http://segment7.net
> This implementation is HODEL-HASH-9600 compliant
>
> http://trackmap.robotcoop.com
>
>
>
>

Sure, but couldn't the parser "flag" blocks that have the exception
handler and only provide support for those cases? I do not see why we
would have to pay the price on every block -- of course you have the
over head when you use it.

pth
Daniel N. (Guest)
on 2006-02-15 16:01
(Received via mailing list)
Pat: I think it already does and there's still a performance hit.
Though Eric's machine chugs a little more than mine, I'd be interested
to see what his ratios are with this added benchmark:

require 'benchmark'

N = 10_000_000

Benchmark.bmbm do |b|
  b.report 'begin' do
    N.times { begin; rescue; end }
  end

  b.report 'begin no rescue' do
    N.times { begin; end }
  end

  b.report 'no begin' do
    N.times { }
  end
end




G:\Documents and Settings\Dan Nugent\Desktop>ruby -v rescue.rb
ruby 1.8.4 (2005-12-24) [i386-mswin32]
Rehearsal ---------------------------------------------------
begin             3.703000   0.000000   3.703000 (  3.844000)
begin no rescue   3.125000   0.000000   3.125000 (  3.281000)
no begin          2.078000   0.000000   2.078000 (  2.172000)
------------------------------------------ total: 8.906000sec

                      user     system      total        real
begin             4.703000   0.000000   4.703000 (  4.906000)
begin no rescue   3.203000   0.000000   3.203000 (  3.312000)
no begin          2.047000   0.000000   2.047000 (  2.141000)

G:\Documents and Settings\Dan Nugent\Desktop>
Dave C. (Guest)
on 2006-02-15 21:06
(Received via mailing list)
On a lark, I did this, and was shocked at the result. Why the massive
difference in performance between "begin; end" within a block, and "{ }"
within a block?

I may do some more tinkering with this later on.

require 'benchmark'

N = 10_000_000

Benchmark.bmbm do |b|
   b.report 'begin' do
     N.times { begin; rescue; end }
   end

   b.report 'begin no rescue' do
     N.times { begin; end }
   end

   b.report 'no begin nested' do
     N.times { { } }
   end

   b.report 'plain' do
     N.times { }
   end
end

Rehearsal ---------------------------------------------------
begin             3.547000   0.000000   3.547000 (  3.656000)
begin no rescue   2.797000   0.000000   2.797000 (  2.860000)
no begin nested  38.062000   0.453000  38.515000 ( 40.593000)
plain             1.735000   0.000000   1.735000 (  1.782000)
----------------------------------------- total: 46.594000sec

                       user     system      total        real
begin             3.516000   0.000000   3.516000 (  3.594000)
begin no rescue   2.750000   0.000000   2.750000 (  2.828000)
no begin nested  36.422000   0.297000  36.719000 ( 38.797000)
plain             1.750000   0.000000   1.750000 (  1.781000)
Dave C. (Guest)
on 2006-02-15 21:06
(Received via mailing list)
Daniel N. wrote:
>     N.times { begin; rescue; end }
>   end
>
>   b.report 'begin no rescue' do
>     N.times { begin; end }
>   end
>
>   b.report 'no begin' do
>     N.times { }
>   end
> end

On my machine, WinXP Home SP2, 512mb RAM, Athlon 1900 (or so). Both
benchmarks run within irb.

Using Eric's original code:

Rehearsal --------------------------------------------
begin      3.578000   0.000000   3.578000 (  3.625000)
no begin   1.782000   0.000000   1.782000 (  1.828000)
----------------------------------- total: 5.360000sec

                user     system      total        real
begin      3.547000   0.000000   3.547000 (  3.625000)
no begin   1.796000   0.000000   1.796000 (  1.812000)

100% increase between the two. Not as much as Eric's, but still
significant I would think.

Using Daniel's code:

Rehearsal ---------------------------------------------------
begin             3.546000   0.000000   3.546000 (  3.625000)
begin no rescue   2.829000   0.000000   2.829000 (  2.875000)
no begin          1.781000   0.000000   1.781000 (  1.828000)
------------------------------------------ total: 8.156000sec

                       user     system      total        real
begin             3.547000   0.000000   3.547000 (  3.609000)
begin no rescue   2.812000   0.000000   2.812000 (  2.891000)
no begin          1.735000   0.000000   1.735000 (  1.797000)


Interesting middle ground there. So begin/end blocks have their own
overhead, above and beyond the exception handlers.

Note that I am not a benchmarking expert, and in fact am merely guessing
at the relative importance of the numbers, assuming the "real" values
are the important ones. I probably should read more about this module.
Logan C. (Guest)
on 2006-02-15 21:15
(Received via mailing list)
On Feb 15, 2006, at 2:03 PM, Dave C. wrote:

>  N.times { { } }

This is equivalent to N.times { Hash.new }
David V. (Guest)
on 2006-02-16 02:25
(Received via mailing list)
DÅ?a Streda 15 Február 2006 20:03 Dave C. napísal:
> On a lark, I did this, and was shocked at the result. Why the massive
> difference in performance between "begin; end" within a block, and "{ }"
> within a block?
>

Because it's a literal hash constructor, not a nested block?

On a slightly related note, the literal hash constructor is apparently
faster
than Hash.new. Good to know.

David V.
unknown (Guest)
on 2006-02-24 19:45
(Received via mailing list)
Hi --

On Mon, 13 Feb 2006, David V. wrote:

>>
> How would you parse the difference whether the raise applies to the whole
> block, or just the previous statement?

I think Daniel's idea would be to have it be the same as with method
bodies.


David

--
David A. Black (removed_email_address@domain.invalid)
Ruby Power and Light (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black
This topic is locked and can not be replied to.