JRuby

allocator undefined for NativeException

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

relates to

Bug - A problem which impairs or prevents the functions of the product. JRUBY-415 All Java classes bound into Ruby should provide an allocator/initialize combo or documentation why they do not

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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.
Hide
Permalink
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

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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: