Can I be a devil's advocate for not "fixing" the JRUBY-4677. Wouldn't this just be fixing a symptom and not the real problem? Isn't the real problem that the ActiveRecord JDBC adapter is throwing native Java exceptions instead of Ruby exceptions? It just seems scary to me that having rescue Exception also catch Java exceptions could lead to some poorly crafted JRuby only code. Where developers are relying on this hidden/magic behavior. If I write a library specifically for JRuby and I want my Ruby code to catch a Java exception I think I should be required to specifically code for this. But in the generally case "rescue Exception" should only do what it says. It should just catch Ruby exceptions.
My 2 cents. Joe On Thu, Apr 8, 2010 at 11:20 AM, Charles Oliver Nutter <[email protected]>wrote: > I've fixed a couple really tricky bugs the past week and I'd like more > eyes on the changes: > > "threadContextMap leaks RubyThread on death of adopted thread" > http://jira.codehaus.org/browse/JRUBY-4264 > Fixed in 364c41a on branch "jruby-4264" > > http://github.com/jruby/jruby/commit/364c41a1ead0666d217856347b1adf2b23d77a90 > > This one introduces a reference queue to ThreadService to clean up old > (leaking, in embedded scenarios) RubyThread instances that accumulated > one per new thread that enters a JRuby runtime. It seems to work fine, > but given that there's no example case to exercise it I'm worried. > Bonus points to come up with a test case that exercises it. > > "jirb_swing broken: JRuby picking wrong constructor, with no obvious > work around" > http://jira.codehaus.org/browse/JRUBY-4680 > Fixed in c1672c4 > > http://github.com/jruby/jruby/commit/c1672c484dac3b59403d16db17c6fbb469d0878a > > This one required some enhancements to how we choose Java methods. > Specifically, it now examines arguments one at a time, ranking better > matches closer to the beginning of the argument list higher. The old > logic (which is still used as a fallback, to handle varargs), scanned > the args all at once, looking for an all "exact" match or an all > "assignable" match and so on. This caused many methods to be equally > valid, and so on different JVMs and different platforms a different > method might be chosen. I'd like someone to just read through my logic > and see if I did anything silly. It also needs a test case. > > "Java exceptions can't be rescued with "rescue Exception"" > http://jira.codehaus.org/browse/JRUBY-4677 > Fixed in 323ba1e > > http://github.com/jruby/jruby/commit/323ba1e629f578e916b0779c421f4fae43a8aece > Follow-up<http://github.com/jruby/jruby/commit/323ba1e629f578e916b0779c421f4fae43a8aece%0AFollow-up>fix > in 091db96 > > http://github.com/jruby/jruby/commit/091db96e56a770487d412d2373f2be79f5f7a5e7 > > This one scares me quite a bit. Recently it was reported here on the > mailing list that a Ruby "rescue Exception" was not rescuing Java > exceptions. Obviously the spirit of "rescue Exception" is to rescue > all exceptional cases, so that they can be handled in some reasonably > graceful way. The result of not rescuing Java exceptions is that it > wasn't possible for Ruby code to cover all possible exits from a body > of code, and in the reporter's case ActiveRecord ended up going ahead > and committing a transaction. The bug is bad, but I'm worried about > the cure. Java exceptions are now examined and caught for all cases of > "rescue Exception" or "rescue Object", which means it's possible for > Ruby code to interfere with the propagation of those exceptions if > it's not careful. It also meant that JRuby-internal exceptions had to > be marked as "Unrescuable" so they would always propagate > appropriately, or else things like catch/throw and non-local > break/return would stop working right in the presence of "rescue > Exception". > > Anyone who has a little time to help review the changes...I'd really > appreciate it :) > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
