[#14696] Inconsistency in rescuability of "return" — Charles Oliver Nutter <charles.nutter@...>

Why can you not rescue return, break, etc when they are within

21 messages 2008/01/02
[#14699] Re: Inconsistency in rescuability of "return" — Gary Wright <gwtmp01@...> 2008/01/02

[#14738] Enumerable#zip Needs Love — James Gray <james@...>

The community has been building a Ruby 1.9 compatibility tip list on

15 messages 2008/01/03
[#14755] Re: Enumerable#zip Needs Love — Martin Duerst <duerst@...> 2008/01/04

Hello James,

[#14772] Manual Memory Management — Pramukta Kumar <prak@...>

I was thinking it would be nice to be able to free large objects at

36 messages 2008/01/04
[#14788] Re: Manual Memory Management — Marcin Raczkowski <mailing.mr@...> 2008/01/05

I would only like to add that RMgick for example provides free method to

[#14824] Re: Manual Memory Management — MenTaLguY <mental@...> 2008/01/07

On Sat, 5 Jan 2008 15:49:30 +0900, Marcin Raczkowski <mailing.mr@gmail.com> wrote:

[#14825] Re: Manual Memory Management — "Evan Weaver" <evan@...> 2008/01/07

Python supports 'del reference', which decrements the reference

[#14838] Re: Manual Memory Management — Marcin Raczkowski <mailing.mr@...> 2008/01/08

Evan Weaver wrote:

[#14911] Draft of some pages about encoding in Ruby 1.9 — Dave Thomas <dave@...>

Folks:

24 messages 2008/01/10

[#14976] nil encoding as synonym for binary encoding — David Flanagan <david@...>

The following just appeared in the ChangeLog

37 messages 2008/01/11
[#14977] Re: nil encoding as synonym for binary encoding — Yukihiro Matsumoto <matz@...> 2008/01/11

Hi,

[#14978] Re: nil encoding as synonym for binary encoding — Dave Thomas <dave@...> 2008/01/11

[#14979] Re: nil encoding as synonym for binary encoding — David Flanagan <david@...> 2008/01/11

Dave Thomas wrote:

[#14993] Re: nil encoding as synonym for binary encoding — Dave Thomas <dave@...> 2008/01/11

[#14980] Re: nil encoding as synonym for binary encoding — Gary Wright <gwtmp01@...> 2008/01/11

[#14981] Re: nil encoding as synonym for binary encoding — Yukihiro Matsumoto <matz@...> 2008/01/11

Hi,

[#14995] Re: nil encoding as synonym for binary encoding — David Flanagan <david@...> 2008/01/11

Yukihiro Matsumoto writes:

[#15050] how to "borrow" the RDoc::RubyParser and HTMLGenerator — Phlip <phlip2005@...>

Core Rubies:

17 messages 2008/01/13
[#15060] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Eric Hodel <drbrain@...7.net> 2008/01/14

On Jan 13, 2008, at 08:54 AM, Phlip wrote:

[#15062] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Phlip <phlip2005@...> 2008/01/14

Eric Hodel wrote:

[#15073] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Eric Hodel <drbrain@...7.net> 2008/01/14

On Jan 13, 2008, at 20:35 PM, Phlip wrote:

[#15185] Friendlier methods to compare two Time objects — "Jim Cropcho" <jim.cropcho@...>

Hello,

10 messages 2008/01/22

[#15194] Can large scale projects be successful implemented around a dynamic programming language? — Jordi <mumismo@...>

A good article I have found (may have been linked by slashdot, don't know)

8 messages 2008/01/24

[#15248] Symbol#empty? ? — "David A. Black" <dblack@...>

Hi --

24 messages 2008/01/28
[#15250] Re: Symbol#empty? ? — Yukihiro Matsumoto <matz@...> 2008/01/28

Hi,

Re: Inconsistency in rescuability of "return"

From: Gary Wright <gwtmp01@...>
Date: 2008-01-03 08:00:30 UTC
List: ruby-core #14713
On Jan 3, 2008, at 1:35 AM, Charles Oliver Nutter wrote:
>
> The problem with this logic is that in case A, the exception also  
> causes the loop to be terminated as normal:
>
> while true
>   eval 'break'
> end
>
> So there's obviously some duality behind break.
>
> 1. A bare break can't be cause as an exception, and terminates an  
> enclosing loop
> 2. A break inside an eval can be caught as an exception, and also  
> terminates an enclosing loop like a normal break.

OK, I just tried this on my box that has 1.9 installed and I see that  
the 1.9 behavior in this case is different than the 1.8 behavior.   
I've been talking about the 1.8 behavior.  To summarize:

1.8, top-level, bare break:  LocalJumpException
1.8, top-level, eval 'break':LocalJumpException
1.8, loop, bare break:       loop terminates
1.8, loop, eval 'break':     loop terminates

So in 1.8 the loop/iterator context is visible within an eval string.

1.9, top-level, bare break:   SyntaxError
1.9, top-level, eval 'break': SyntaxError
1.9, loop, bare break:        loop terminates
1.9, loop, eval 'break':      SyntaxError

So in 1.9 eval is creating a 'stronger' scope than in 1.8 and hiding  
the loop/iterator context from the code in the string that is being  
evaluated.  In this new, more private, context a bare break is always  
a syntax error.  It doesn't matter where the eval is taking place.

I'm not sure I understand you second point above. If you catch the  
syntax error with a rescue clause within the loop, then the loop  
won't be terminated.  If you don't catch the error then the loop will  
be terminated.  But this is just the normal behavior of any sort of  
exception--there is nothing special about 'break' in this case--any  
old syntax error would do the same thing.

It seems like the 1.9 behavior is more consistent with the fact that  
eval does create a new scope of sorts. The fact that the iterator  
context leaked into the 1.8 eval string scope seems more like a bug  
than a feature.

Gary Wright

In This Thread