Home » Java » ArithmeticException: “Non-terminating decimal expansion; no exact representable decimal result”

ArithmeticException: “Non-terminating decimal expansion; no exact representable decimal result”

Posted by: admin November 2, 2017 Leave a comment


Why does the following code raise the exception shown below?

BigDecimal a = new BigDecimal("1.6");
BigDecimal b = new BigDecimal("9.2");
a.divide(b) // results in the following exception.

java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.

From the Java 5 docs (Java 8 docs here):

When a MathContext object is supplied with a precision setting of 0 (for
example, MathContext.UNLIMITED), arithmetic operations are exact, as
are the arithmetic methods which take no MathContext object. (This is the
only behavior that was supported in releases prior to 5.)

As a corollary of computing the exact result, the rounding mode setting of a MathContext
object with a precision setting of 0 is not used and thus irrelevant. In
the case of divide, the exact quotient could have an infinitely long decimal
expansion; for example, 1 divided by 3.

If the quotient has a nonterminating decimal expansion and
the operation is specified to return an exact result, an ArithmeticException is thrown.
Otherwise, the exact result of the division is returned, as done for
other operations.

To fix, you need to do something like this:

a.divide(b, 2, RoundingMode.HALF_UP)

where 2 is precision and RoundingMode.HALF_UP is rounding mode

More details: http://jaydeepm.wordpress.com/2009/06/04/bigdecimal-and-non-terminating-decimal-expansion-error/


Because you’re not specifying a precision and a rounding-mode. BigDecimal is complaining that it could use 10, 20, 5000, or infinity decimal places, and it still wouldn’t be able to give you an exact representation of the number. So instead of giving you an incorrect BigDecimal, it just whinges at you.

However, if you supply a RoundingMode and a precision, then it will be able to convert (eg. 1.333333333-to-infinity to something like 1.3333 … but you as the programmer need to tell it what precision you’re ‘happy with’.


You can do

a.divide(b, MathContext.DECIMAL128)

You can choose the number of bits you want either 32,64,128.

Check out this link :



For fixing such an issue I have used below code

a.divide(b, 2, RoundingMode.HALF_EVEN)

2 is precision. Now problem was resolved.


I had this same problem, because my line of code was:

txtTotalInvoice.setText(var1.divide(var2).doubleValue() + "");

I change to this, reading previous Answer, because I was not writing decimal precision:

txtTotalInvoice.setText(var1.divide(var2,4, RoundingMode.HALF_UP).doubleValue() + "");

4 is Decimal Precion

AND RoundingMode are Enum constants, you could choose any of this

In this Case HALF_UP, will have this result:

2.4 = 2   
2.5 = 3   
2.7 = 3

You can check the RoundingMode information here: http://www.javabeat.net/precise-rounding-of-decimals-using-rounding-mode-enumeration/


Answer for BigDecimal throws ArithmeticException

public static void main(String[] args) {
        int age = 30;
        BigDecimal retireMentFund = new BigDecimal("10000.00");
        BigDecimal yearsInRetirement = new BigDecimal("20.00");
        String name = " Dennis";
        for ( int i = age; i <=65; i++){
            recalculate(retireMentFund,new BigDecimal("0.10"));
        BigDecimal monthlyPension =   retireMentFund.divide(
                yearsInRetirement.divide(new BigDecimal("12"), new MathContext(2, RoundingMode.CEILING)), new MathContext(2, RoundingMode.CEILING));      
        System.out.println(name+ " will have £" + monthlyPension +" per month for retirement");
public static void recalculate (BigDecimal fundAmount, BigDecimal rate){
        fundAmount.multiply(rate.add(new BigDecimal("1.00")));

Add MathContext object in your divide method call and adjust precision and rounding mode. This should fix your problem


it is because the Bigdecimal has no lost, and if you divide 1/3 for example, it will result in a repeating decimal to infinity. 0.33333333… theoretically if you multiply back, you receive the exact result. But a infinity number will generate stack over flow and in this case the exception is launched.

My solution:

 try {
     result = n1.divide(n2);
 } catch (ArithmeticException e){
     Log.d("Error bigdecimal", e.toString());
     result = (n1.doubleValue()/n2.doubleValue());

in this case your result will not be cutted by Rounding