Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: JRuby 1.7.0.pre1
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Was attempting to perform the Ruby equivalent of wrapping a message. In this case just adding a bit more info before re-raising the exception. The code snippet below creates raises an unpected "allocator undefined for NativeException" in the rescue block.

      rescue Exception => e
        tx.rollback if tx
        raise e.exception("#{e.message}: while parsing chunk '#{chunked_stream}'")
      ensure
        session.close
      end
      

      The work-around was to log and raise the Java exception unmodified. Nothing painful, but I would like the #exception method to work the same on Ruby and Java exceptions. In my case I am working with highly threaded code and having interleaved error messages a bit difficult to tease apart.

        Issue Links

          Activity

          Hide
          Hiro Asari added a comment -

          What's causing the native exception? I can't reproduce the problem you are describing with the information at hand.

          Show
          Hiro Asari added a comment - What's causing the native exception? I can't reproduce the problem you are describing with the information at hand.
          Show
          Hiro Asari added a comment - Actually, I understand the problem now. See JRUBY-415 , and also: https://github.com/jruby/jruby/blob/fd0fa789b21b30f294e8286b72b75fe3b688c27a/src/org/jruby/NativeException.java#L55-56
          Hide
          Charles Oliver Nutter added a comment -

          I don't see any reason we couldn't just add an allocator for it. NativeException predates my time on the project, so it may just have been happenstance that we never added one.

          Show
          Charles Oliver Nutter added a comment - I don't see any reason we couldn't just add an allocator for it. NativeException predates my time on the project, so it may just have been happenstance that we never added one.
          Hide
          Hiro Asari added a comment -

          The spec is pushed to the master: 722feca

          And the fix is: 725be64

          Show
          Hiro Asari added a comment - The spec is pushed to the master: 722feca And the fix is: 725be64
          Hide
          Arturas Slajus added a comment -

          Why is this on 1.7? :/ Can't it be backported to 1.6?

          Show
          Arturas Slajus added a comment - Why is this on 1.7? :/ Can't it be backported to 1.6?
          Hide
          Hiro Asari added a comment -

          Arturas,

          I feel that this is a behavior change that needs to be tested. Is there a library or application that needs to re-raise a NativeException?

          Show
          Hiro Asari added a comment - Arturas, I feel that this is a behavior change that needs to be tested. Is there a library or application that needs to re-raise a NativeException?
          Hide
          Arild Shirazi added a comment -

          What do you mean? Obviously I ran into problems because I could not re-raise an expception in threaded code, and thus was not able to get information about the thread on which the exception was raised!

          And I have provided you with an example above!

          As a Ruby programmer I had an unexpected exception in my error handling code simply because I was running in JRuby and not Ruby.

          This is a violation of Liskov substitution principle, as well as a crappy surprise for the unwary Rubyist.

          Show
          Arild Shirazi added a comment - What do you mean? Obviously I ran into problems because I could not re-raise an expception in threaded code, and thus was not able to get information about the thread on which the exception was raised! And I have provided you with an example above! As a Ruby programmer I had an unexpected exception in my error handling code simply because I was running in JRuby and not Ruby. This is a violation of Liskov substitution principle, as well as a crappy surprise for the unwary Rubyist.
          Hide
          Hiro Asari added a comment -

          Oops. Sorry about that. I probably confused a few users while I was looking at multiple tickets simultaneously. I'll confer with Tom to see if this is OK to cherry-pick to the 1.6 branch.

          Show
          Hiro Asari added a comment - Oops. Sorry about that. I probably confused a few users while I was looking at multiple tickets simultaneously. I'll confer with Tom to see if this is OK to cherry-pick to the 1.6 branch.
          Hide
          Arild Shirazi added a comment -

          Cool. Thanks for your work, and for looking into this. I do appreciate it!

          Show
          Arild Shirazi added a comment - Cool. Thanks for your work, and for looking into this. I do appreciate it!

            People

            • Assignee:
              Hiro Asari
              Reporter:
              Arild Shirazi
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: