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.
70c8da82d09d3866222976ab8978133c?d=identicon&s=25 Daniel Nugent (Guest)
on 2006-02-12 19: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,
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-12 19:44
(Received via mailing list)
DÅ?a Nedeľa 12 Február 2006 19:26 Daniel Nugent 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 Vallner
70c8da82d09d3866222976ab8978133c?d=identicon&s=25 Daniel Nugent (Guest)
on 2006-02-12 19: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)...
Ce60c4f78a63b0695e4dafc4bd7964f7?d=identicon&s=25 Lou Vanek (Guest)
on 2006-02-12 20: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
52a177e9dbd3e614825aabc4e45f8cd6?d=identicon&s=25 Mark Volkmann (Guest)
on 2006-02-12 20:39
(Received via mailing list)
On 2/12/06, Lou Vanek <vanek@acd.net> 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.
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-12 21:24
(Received via mailing list)
DÅ?a Nedeľa 12 Február 2006 20:39 Mark Volkmann 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 Volkmann
> 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 Vallner
70c8da82d09d3866222976ab8978133c?d=identicon&s=25 Daniel Nugent (Guest)
on 2006-02-12 21: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?
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-12 22: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 Vallner

Dòa Nedeµa 12 Február 2006 21:43 Daniel Nugent napísal:
70c8da82d09d3866222976ab8978133c?d=identicon&s=25 Daniel Nugent (Guest)
on 2006-02-12 22: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.
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-12 23:10
(Received via mailing list)
Dòa Nedeµa 12 Február 2006 22:46 Daniel Nugent 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 Vallner
2c51fec8183a5d21c4e11b430beabb47?d=identicon&s=25 Patrick Hurley (Guest)
on 2006-02-13 17:20
(Received via mailing list)
On 2/12/06, David Vallner <david@vallner.net> wrote:
>
> <dense>D'oh. Didn't know that one... </dense>
>
>
> David Vallner
>
>

+1
70c8da82d09d3866222976ab8978133c?d=identicon&s=25 Daniel Nugent (Guest)
on 2006-02-13 20:30
(Received via mailing list)
So, maybe this calls for a RCR?

I know for sure that I'd like blocks to be rescuable.
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-14 22:29
(Received via mailing list)
Dòa Pondelok 13 Február 2006 17:20 Patrick Hurley napísal:
> +1
>

Die.

David Vallner
Allergic to anything remotely resembling slashdot
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-02-14 23:36
(Received via mailing list)
On Feb 12, 2006, at 10:55 AM, Daniel Nugent 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 Hodel - drbrain@segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
D63c268960051bc17a310aa29fffd979?d=identicon&s=25 Dave Cantrell (Guest)
on 2006-02-15 04:53
(Received via mailing list)
Eric Hodel 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
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-02-15 06:51
(Received via mailing list)
Dave Cantrell 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
D63c268960051bc17a310aa29fffd979?d=identicon&s=25 Dave Cantrell (Guest)
on 2006-02-15 07:06
(Received via mailing list)
Hal Fulton 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
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-02-15 07:18
(Received via mailing list)
Dave Cantrell 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
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-02-15 09:55
(Received via mailing list)
On Feb 14, 2006, at 9:50 PM, Hal Fulton 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 Hodel - drbrain@segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
2c51fec8183a5d21c4e11b430beabb47?d=identicon&s=25 Patrick Hurley (Guest)
on 2006-02-15 12:29
(Received via mailing list)
On 2/15/06, Eric Hodel <drbrain@segment7.net> 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 Hodel - drbrain@segment7.net - 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
70c8da82d09d3866222976ab8978133c?d=identicon&s=25 Daniel Nugent (Guest)
on 2006-02-15 15: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>
D63c268960051bc17a310aa29fffd979?d=identicon&s=25 Dave Cantrell (Guest)
on 2006-02-15 20: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)
D63c268960051bc17a310aa29fffd979?d=identicon&s=25 Dave Cantrell (Guest)
on 2006-02-15 20:06
(Received via mailing list)
Daniel Nugent 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.
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-02-15 20:15
(Received via mailing list)
On Feb 15, 2006, at 2:03 PM, Dave Cantrell wrote:

>  N.times { { } }

This is equivalent to N.times { Hash.new }
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-16 01:25
(Received via mailing list)
DÅ?a Streda 15 Február 2006 20:03 Dave Cantrell 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 Vallner
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-02-24 18:45
(Received via mailing list)
Hi --

On Mon, 13 Feb 2006, David Vallner 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 (dblack@wobblini.net)
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.