break/return does not become a LocalJumpError when it should
------------------------------------------------------------
Key: JRUBY-2760
URL: http://jira.codehaus.org/browse/JRUBY-2760
Project: JRuby
Issue Type: Bug
Components: Miscellaneous
Affects Versions: JRuby 1.1.3
Reporter: Charles Oliver Nutter
So it turns out that the test_local_jump_error test has been running, but not
actually running. I discovered it when I made various fixes and improvements to
non-local flow control that appear to have made it a hard failure:
Before:
{noformat}
~/NetBeansProjects/jruby ➔ jruby -X-C test/test_local_jump_error.rb
Loaded suite test/test_local_jump_error
Started
Finished in 0.062 seconds.
0 tests, 0 assertions, 0 failures, 0 errors
{noformat}
After:
{noformat}
~/NetBeansProjects/jruby ➔ jruby -X-C test/test_local_jump_error.rb
Loaded suite test/test_local_jump_error
Started
:1: break from proc-closure (LocalJumpError)
{noformat}
So it wasn't working before either. I'm going to disable the test, and I'm
filing this bug.
The only way I can see to make this and other LJE cases work right would be to
inspect the frame stack and see if the target frame/jumpTarget is still there,
but since we preallocate frames and jump targets it would end up being wrong.
Also look at this return case:
Not rescuable:
{noformat}
def foo
bar(Proc.call {return})
end
def bar(proc)
begin
proc.call
rescue LocalJumpError
puts 'here'
end
end
foo # no output
{noformat}
Rescuable:
{noformat}
def foo
Proc.call {return}
end
def bar(proc)
begin
proc.call
rescue LocalJumpError
puts 'here'
end
end
bar(foo) # output 'here'
{noformat}
So the return is rescuable only in the case where it has escaped from its
original containing method. Damned frustrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
