Java BigDecimal 除法出现 ArithmeticException 时怎么选精度

调用 BigDecimal.divide(divisor) 后出现 ArithmeticException，通常不是 BigDecimal 失去精度，而是代码要求返回“精确结果”，但商是无限循环小数。比如 1/3 没有有限的十进制表示；金额计算应先决定保留几位，比例或统计值则可以用 MathContext 指定有效数字。除数为零仍然是另一类错误，不能靠舍入模式掩盖。

处理这类异常的关键是把业务精度写进 divide 重载：固定小数位用 scale + RoundingMode，需要有效数字用 MathContext，需要严格禁止误差则使用 RoundingMode.UNNECESSARY。

Java BigDecimal.divide 为什么会抛 ArithmeticException

BigDecimal 的无参数 divide 会尝试返回精确商。1/4 可以得到 0.25，1/3 却会无限展开，因此实现没有一个有限的 BigDecimal 能同时满足“精确”和“有限表示”两个条件。Oracle 文档也明确说明，非终止十进制展开在要求精确结果时会抛出该异常。

可以先把两种情况分开记录：

金额计算先固定小数位，再选择舍入方式

发票金额、单价分摊、税率换算等场景，业务往往规定结果保留 2 位或 4 位小数。这时不要先无参数除法再捕获异常，而是把小数位和舍入方向直接写入调用：

import java.math.BigDecimal;
import java.math.RoundingMode;

public class MoneyDivideDemo {
    public static void main(String[] args) {
        BigDecimal total = new BigDecimal("10.00"); // 用字符串保留十进制输入
        BigDecimal pieces = new BigDecimal("3");

        // 金额按 2 位小数输出，HALF_UP 明确处理第 3 位
        BigDecimal unit = total.divide(pieces, 2, RoundingMode.HALF_UP);
        System.out.println(unit.toPlainString()); // 3.33
    }
}

这里的 2 是结果的 scale，不是“总共保留 2 位有效数字”。如果业务规定银行家舍入，可换成 RoundingMode.HALF_EVEN；如果只截断，则使用 DOWN，但必须确认截断不会造成结算偏差。

需要有效数字时，用 MathContext 控制整体精度

科学计算、汇率中间值或统计比例不一定固定小数位，更适合表达“保留 8 位有效数字”。此时使用 MathContext，其中 precision 控制从左侧第一个非零数字开始计算的总位数，RoundingMode 决定被舍弃数字如何影响结果：

import java.math.BigDecimal;
import java.math.MathContext;
import java.math.RoundingMode;

public class PrecisionDivideDemo {
    public static void main(String[] args) {
        MathContext context = new MathContext(8, RoundingMode.HALF_UP); // 8 位有效数字
        BigDecimal numerator = new BigDecimal("123456.789"); // 十进制输入
        BigDecimal denominator = new BigDecimal("17");

        // 适合比例/中间量，不等同于固定 8 位小数
        BigDecimal result = numerator.divide(denominator, context);
        System.out.println(result.toPlainString());
    }
}

不要把 MathContext(8, ...) 当成金额保留 8 位小数。若最终要入账，仍应在业务边界用 setScale(2, ...) 或固定 scale 的 divide 做一次明确落位。连续多步运算时，还要统一中间精度，避免某一步提前舍入。

严格不允许误差时，让 UNNECESSARY 负责校验

有些协议或分摊规则要求“只能整除，不能静默舍入”。可以指定 RoundingMode.UNNECESSARY，一旦结果需要丢弃数字就抛出 ArithmeticException，让调用方转入人工审核、补差额或重新分配：

BigDecimal amount = new BigDecimal("10.00"); // 原始金额
BigDecimal count = new BigDecimal("4");

// 只能得到精确到 2 位的结果，否则用异常暴露规则冲突
BigDecimal exact = amount.divide(count, 2, RoundingMode.UNNECESSARY);

这不是生产代码里的通用“防异常”方案，而是一个有意的约束。测试中应覆盖 10/4、10/3 和除数为 0 三类边界，并检查异常发生在预期层级。

常见问题

为什么把 divide 写进 try-catch 仍然不推荐？

捕获异常只能知道精确除法失败，却不知道业务应该保留几位或向哪边舍入。应先确定规则，再选择 divide 重载。

BigDecimal 的构造为什么要避免 new BigDecimal(double)？

double 已经是二进制浮点数，直接构造可能把二进制误差带入十进制计算。金额输入优先使用字符串或 BigDecimal.valueOf。

setScale 和 divide 的 scale 有什么区别？

divide 的 scale 参与除法结果的生成；setScale 是对已有值调整表示和舍入。两者都要配合明确的 RoundingMode。

最后可以把精度决策写成代码评审清单：输入是否来自字符串、除数是否可能为零、结果是固定小数位还是有效数字、舍入模式是否符合结算规则，以及测试是否覆盖非终止小数。这样 ArithmeticException 就不再是偶发故障，而是精度策略没有被表达出来的提醒。