> > > Does this mean that computations can "unpredictably" overflow > (or throw an exception)? >
The ArithmeticUtils() methods mulAndCheck and addAndCheck throw exceptions if there is overflow during primitive operations. That is the "check" part of the method name. > Is it acceptable, or should we enclose the problematic code in > a "try" block and redo the computation with "BigInteger" when > necessary? > > What is the performance hit of using "BigFraction" rather than > "Fraction"? > I once used BigDecimal for a project, it is great code but the performance is nothing close to using primitives. > Are there use-cases that would need the ultimate performance from > "Fraction" while not worry about overflow? > You would need a greatest common factor between the two fractions that was larger than 64 bits. Again, BigFraction is there for anyone worried about such a case and there is no significant performance hit to switching over to BigFraction compared to a Fraction class that was using BigInteger under the hood. But I suspect there would be a substantial performance gain if longs were being used under the hood for the Fraction class for the more common use case of smaller fractions. If it would be best practice, a bit of microbenchmarking could be done to check. A FractionOverflowException could be specifically tailored to this use case and the error message can suggest using BigFraction. Or as you suggest, the catch block could silently or with warning return a BigFraction. If we have class inheritance straight, and both Fraction and BigFraction have the exact same interface, this could be an elegant solution. Eric
