[ji] allow Java errors from Ruby threads to reach the handler#6679
[ji] allow Java errors from Ruby threads to reach the handler#6679headius merged 11 commits intojruby:masterfrom
Conversation
5879b7a to
ea82acf
Compare
ea82acf to
b8a240a
Compare
|
one potential concern for improvement, even though |
|
Good point! I think we would want to still report that as the terminal exception for the thread. |
* master: (165 commits) Also remove pending_interrupt? tags Thread.current.raise should also set interrupt Cleanup TestThread excludes Thread.current.raise should honor interrupt mask Add uninterruptible logic for Kernel#p Rework Queue#pop to restore retry loop Separate blocking from nonblocking tasks RUBY not RB Should use blocking thread poll before IO op This should be && Add tags for new failing specs Update to ruby/spec@b65d01f Update to ruby/mspec@9542a88 Do not loop at this level, caller should loop Document what this lines up with in CRuby Add blocking thread poll Update handle_interrupt tags Address review comment Split up Windows and Solaris FFI file logic Avoid checking FFI constants for usability ...
* master: (63 commits) Bump metaspace up 50% to see if we are leaking Update test_ftp to get stdlib tests green Update version numbers to match CRuby 2.6.8 Update stdlib files not sourced from gems Updated jossl is a bit larger Switch to released ffi 1.15.4 Update rexml to 3.1.9.1 to match ruby 2.6.8 ffi 1.15.4 Update owned dependencies backport9 and options Missed an updated pom.xml for jffi Update did_you_mean to 1.3.0 to match ruby 2.6.8 Update to jruby-openssl 0.10.7 Update JNR dependencies restore api compatibility with nio4r Create and use pure-bash dirname and basename update surefire plugin tags off TestBigDecimal#test_new and TestBigMath#test_sqrt because these already pass. fix failing TestBigDecimal#test_ctov fix failing TestBigDecimal#test_to_special_string fix failing TestBigDecimal#test_power_of_negative_infinity, #test_power_of_positive_infinity and #test_power_of_zero ...
|
hmm, seems like bubbling up Java errors is revealing a bug with test/unit's parallel test runner: not sure I guess we would need an uncaught Java handler during the MRI suite why this suddenly matters ... |
spec/regression/GH-1106_fiber_must_propagate_java_exceptions_spec.rb
Outdated
Show resolved
Hide resolved
test workers were dying because any |
|
I'm going to untarget this until it looks like we have a release target in mind. |
Co-authored-by: Pavel Rosický <pdahorek@seznam.cz>
000413d to
b4d61c6
Compare
java.lang.Errorinstances will no longer be considered exiting exceptions for Ruby threads,the Ruby thread instance will instead bubble these out and let the Java level uncaught handler take care of these.
this changes JRuby user-behavior in cases such as:
Thread.start { raise java.lang.Error.new('bleh') }but the risk of breakage is legit opposed to potentially "handling" errors such asjava.lang.OutOfMemoryErrorat the Ruby level.besides, there's also some new Java API being exposed on the
RubyThreadas well as naming unification forabortOnExceptionnaming on theRubyruntime + MRI handlesreport_on_exceptionas a true/false flag - no special handling for nil necessary. HINT: JRuby did return the incorrect object onThread#report_on_exceptionand friends.