[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903381#comment-16903381
]
Heinrich Bohne commented on NUMBERS-99:
---------------------------------------
You're right, this issue is still open. However, the problem is that I found a
gaping hole in the public contract of the {{Fraction}} class: Since the
positivity of the denominator is an implementation detail, the exact
circumstances under which the factory method {{of(int, int)}} will throw an
{{ArithmeticException}} remain a mystery to the user, which means that this
factory method is essentially unpredictable when only going by the
specification and not the implementation.
I thought that this might be solvable by simply _not_ requiring the stored
denominator to be positive, but this would probably break a lot of
functionality whose implementation would have to be adjusted, so this should be
discussed on the dev mailing list. But since the resolution of this bug would
also depend on what course of action will be taken with regard to the issue I
just mentioned, I thought it might be better to leave this issue open, for now.
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
> ----------------------------------------------------------------------------
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
> Reporter: Heinrich Bohne
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
