All these work .. so, perhaps IR is broken for that webrick method .. could be ensure-related. Doing a quick test now and going to bed. But, that is where one of us should look whoever gets to its first.

[subbu@earth ~/jruby] jruby -e 'Thread.new { return }.join'
LocalJumpError: unexpected return
-e_CLOSURE_1__-e_0 at -e:1
[subbu@earth ~/jruby] jruby -e 'begin; Thread.new { return }.join; rescue; end'
[subbu@earth ~/jruby] jruby -e 'begin; Thread.new { return }.join; rescue StandardError =>e; end'

Reproducible on this snippet (jruby 1.7 and jruby 9k both fail on this). The problem is that the ensure executes before the return does (because of ensure-block cloning). However, the return should have ideally executed before the ensure which would have thrown the LJE and would have been caught => control won't get to the ensure before.

But, this highlights a flaw in our ensure handling. However, this is an edge case that only affects LJEs from returns that are caught in code regions that are nested inside other regions with ensures.

Thread.new {
  begin
    begin
      return
    rescue StandardError => e
      p "Error #{e}"
    end
    p 'got out!'
  ensure
    p 'ensured!'
  end
}.join

subbu@earth:/jruby$ jruby -v
jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_72-b14 +jit [linux-amd64]
subbu@earth:/jruby$ jruby -X-C /tmp/thr.rb
"ensured!"
LocalJumpError: unexpected return
subbu@earth:/jruby$ rvm use ruby-head
Using /home/subbu/.rvm/gems/ruby-head
subbu@earth:/jruby$ ruby -v
ruby 2.2.0dev (2014-11-07 trunk 48312) [x86_64-linux]
subbu@earth:~/jruby$ ruby /tmp/thr.rb
"Error unexpected return"
"got out!"
"ensured!"
[subbu@earth ~/jruby] jruby -v
jruby 9.0.0.0.dev-SNAPSHOT (2.2.0p0) 2014-11-07 70cb9a9 Java HotSpot(TM) 64-Bit Server VM 24.72-b04 on 1.7.0_72-b14 +jit [linux-amd64]
[subbu@earth ~/jruby] jruby -X-C /tmp/thr.rb
"ensured!"
LocalJumpError: unexpected return
(root) at /tmp/thr.rb:10

I think this would have worked properly in an earlier version of the IR interpreter from 18 odd months back :) .. unverified statement ...

Fixed in 9ba99c1