ArithmeticException 不仅由除零引发，还包括整数溢出（通过 Math.*Exact 方法）、BigDecimal 除法精度不足、BigInteger 负模或除零等场景，需按类型严格校验边界。
ArithmeticException 不只是除零，大数溢出也会抛
Java 的 ArithmeticException 确实最常见于整数除零（/ 或 %），但另一个高频触发点是整数算术溢出——前提是用了 Math.addExact()、Math.multiplyExact() 这类“精确运算”方法。它们不依赖 JVM 默认的静默溢出行为，而是主动检查并抛异常。
- 普通
int a = Integer.MAX_VALUE + 1;不会抛异常，结果是Integer.MIN_VALUE（回绕） - 但
Math.addExact(Integer.MAX_VALUE, 1)会立刻抛ArithmeticException: integer overflow - 同理，
Math.multiplyExact(100000, 100000)在 int 范围内就可能溢出，也抛这个异常 -
long类型同理，对应方法是Math.addExact(long, long)等
BigDecimal 用错 scale 或 roundingMode 会抛 ArithmeticException
很多人以为 BigDecimal 是“绝对安全”的大数类型，其实它在除法（divide()）时极易因精度问题抛 ArithmeticException，错误信息通常是 Non-terminating decimal expansion; no exact representable decimal result。
- 直接调用
bigDec1.divide(bigDec2)（无参数）时，如果除不尽且无法用有限小数表示（如1/3），就会抛异常 - 必须显式指定
scale和RoundingMode：例如bigDec1.divide(bigDec2, 10, RoundingMode.HALF_UP) - 漏掉
RoundingMode参数（只传scale）仍会抛异常，因为重载方法要求二者同时存在 - 用
divideToIntegralValue()可避免该异常，但它只返回商的整数部分，丢弃余数
BigInteger 的 divide() 除零和负模运算陷阱
BigInteger 虽然不会整数溢出，但它的 divide() 和 remainder() 方法对边界条件很敏感，稍不注意就抛 ArithmeticException。
-
new BigInteger("0").divide(new BigInteger("1"))没问题；但new BigInteger("1").divide(BigInteger.ZERO)抛异常 —— 除零判断是基于值，不是引用 -
BigInteger.remainder()要求除数非零，否则抛ArithmeticException: BigInteger divide by zero - 更隐蔽的是：
BigInteger.mod()要求除数为正数，若传入负数（如mod(new BigInteger("-5"))），会抛ArithmeticException: BigInteger: modulus not positive - 想做带符号取模，得用
remainder()，但要注意它不保证结果非负（remainder符号跟随被除数）
自定义数值类或封装工具时容易忽略的校验点
如果你封装了类似 SafeInt 或 PreciseDecimal 工具类，很容易只防除零，却漏掉其他触发路径。
立即学习“Java免费学习笔记（深入）”；
- 调用
Math.*Exact()前没做输入范围预判，导致生产环境突然崩溃 - 包装
BigDecimal的divide方法时，把RoundingMode写死成UNNECESSARY，而没意识到这仅适用于能整除的场景 - 用
BigInteger.mod()做哈希或索引计算时，误把用户可控的参数直接传入，结果对方传负数就炸了 - 日志里只打印
e.toString()，看不出是除零还是溢出还是模非法，建议至少打e.getMessage()并检查异常类型分支
真正麻烦的不是异常本身，而是不同数值类型（int/long/BigInteger/BigDecimal）对“算术错误”的定义完全不同，同一个业务逻辑换种类型实现，异常触发条件就变了。别假设“不会溢出”或“除数肯定正”，每处数值操作都得按实际类型查文档确认边界行为。
