Fixing RubyBasicObject#compareTo bug. #600
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
All IRubyObjects implement Comparable and the default compareTo implementation delegates to <=>. When the ruby object doesn't implement <=>, ruby raises a NoMethodError. Because compareTo is called from java but the exception raised is in ruby, the exception makes no sense: it has the ruby stack when ruby called into java. For example, this happened on an Iterator that kept min and max references. This iterator was implemented in java, but called by ruby so the exception's stack ended with the call to next in java::lang::Iterator#each, but was a NoMethodError for <=>. This fix catches the NoMethodError and throws an IllegalArgumentException wrapping it. This isn't a great solution because java callers expect compareTo to succeed when objects implement Comparable. There may be a better java exception to throw. This also updates the javadoc to avoid confusion. In older versions, specifically 1.6.7, the op_cmp java method is called and returns nil. Then nil is assumed to be an Integer and coerced, which produces a TypeError. To be safe, this fix also checks the return value for nil when <=> succeeds and throws another IllegalArgumentException.
BanzaiMan
added a commit
that referenced
this pull request
Apr 13, 2013
Fixing RubyBasicObject#compareTo bug.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All IRubyObjects implement Comparable and the default compareTo implementation
delegates to <=>. When the ruby object doesn't implement <=>, ruby raises a
NoMethodError. Because compareTo is called from java but the exception raised
is in ruby, the exception makes no sense: it has the ruby stack when ruby
called into java. For example, this happened on an Iterator that kept min and
max references. This iterator was implemented in java, but called by ruby so
the exception's stack ended with the call to next in java::lang::Iterator#each,
but was a NoMethodError for <=>.
This fix catches the NoMethodError and throws an IllegalArgumentException
wrapping it. This isn't a great solution because java callers expect compareTo
to succeed when objects implement Comparable. There may be a better java
exception to throw. This also updates the javadoc to avoid confusion.
In older versions, specifically 1.6.7, the op_cmp java method is called and
returns nil. Then nil is assumed to be an Integer and coerced, which produces a
TypeError. To be safe, this fix also checks the return value for nil when <=>
succeeds and throws another IllegalArgumentException.
Test update included for RubyHash.