JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-6978

try/rescue should treat native Exceptions like rubys StandardError

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.7.0
    • Fix Version/s: JRuby 1.7.1
    • Component/s: Core Classes/Modules
    • Labels:
      None
    • Number of attachments :
      0

      Description

      This is a followup of JRUBY-6977

      The ruby 'rescue => e' should catch 'normal' Java exceptions (Exceptions which extend java.lang.Exception). On the other hand, java.lang.Error should probably be ignored. This used to be the behaviour before 1.7.0.

      Headius and Enebo discussed in the IRC chat that java.lang.Exception should be treated like Ruby's StandardError Exceptions.

      Thanks!
      Reto

        Issue Links

          Activity

          Hide
          Charles Oliver Nutter added a comment -
          commit 6b13c46b6880b7a7b1f4b71102c0620eeb542d73
          Author: Charles Oliver Nutter <headius@headius.com>
          Date:   Wed Nov 7 20:19:07 2012 -0600
          
              Fix JRUBY-6978
              
              Allow Java exceptions to be rescued by StandardError as well.
              
              Java exceptions do not fit into the Ruby exception hierarchy, so
              we have to special-case logic to handle them. You can rescue a
              Java exception using any of the following:
              
              rescue Object # rescues all Ruby and Java exceptions
              rescue Exception # rescues all Ruby and Java exceptions
              rescue StandardError # rescues StandardError and Java exceptions
              rescue NativeException # rescues and wraps Java exceptions
              rescue <actual Java type> # rescues that type of Java exception
              
              Java exceptions should duck-type as Ruby exceptions, but users
              must keep in mind that Java exceptions will not always be the
              exact type they are rescuing.
          
          :100644 100644 4b0570f... 17b5c74... M	spec/java_integration/exceptions/rescue_spec.rb
          :100644 100644 b957850... 8301af0... M	src/org/jruby/RubyException.java
          :100644 100644 22c955d... c9e135e... M	src/org/jruby/ast/RescueNode.java
          :100644 100644 2e95372... 569ca7d... M	src/org/jruby/javasupport/util/RuntimeHelpers.java
          
          Show
          Charles Oliver Nutter added a comment - commit 6b13c46b6880b7a7b1f4b71102c0620eeb542d73 Author: Charles Oliver Nutter <headius@headius.com> Date: Wed Nov 7 20:19:07 2012 -0600 Fix JRUBY-6978 Allow Java exceptions to be rescued by StandardError as well. Java exceptions do not fit into the Ruby exception hierarchy, so we have to special-case logic to handle them. You can rescue a Java exception using any of the following: rescue Object # rescues all Ruby and Java exceptions rescue Exception # rescues all Ruby and Java exceptions rescue StandardError # rescues StandardError and Java exceptions rescue NativeException # rescues and wraps Java exceptions rescue <actual Java type> # rescues that type of Java exception Java exceptions should duck-type as Ruby exceptions, but users must keep in mind that Java exceptions will not always be the exact type they are rescuing. :100644 100644 4b0570f... 17b5c74... M spec/java_integration/exceptions/rescue_spec.rb :100644 100644 b957850... 8301af0... M src/org/jruby/RubyException.java :100644 100644 22c955d... c9e135e... M src/org/jruby/ast/RescueNode.java :100644 100644 2e95372... 569ca7d... M src/org/jruby/javasupport/util/RuntimeHelpers.java

            People

            • Assignee:
              Charles Oliver Nutter
              Reporter:
              Reto Schüttel
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: