ArithmeticException仅在整数除零（/或%）及Integer.MIN_VALUE / -1时抛出，浮点数除零返回Infinity/NaN，空值运算抛NullPointerException，编译期常量除零直接报错。
Java中ArithmeticException的触发条件
它只在整数除零（/或%）时抛出，浮点数除零不会触发该异常——而是返回Infinity或NaN。这是最常被误判的一点：很多人以为所有“除零”都抛ArithmeticException，其实double a = 5.0 / 0.0;完全合法。
-
int x = 10 / 0;→ 抛ArithmeticException -
long y = 100L % 0;→ 同样抛异常 -
float z = 10.0f / 0.0f;→ 返回Infinity，不抛异常 -
int n = Integer.MIN_VALUE / -1;→ 也抛ArithmeticException（溢出导致的特殊除法）
捕获与处理ArithmeticException的合理方式
不要无差别catch (ArithmeticException e)后吞掉异常或打印堆栈就完事。重点是判断是否属于可预期的业务逻辑分支——比如用户输入了除数为0的表单，应提示“除数不能为零”，而不是让程序崩溃。
- 对用户输入参与的运算，优先在计算前校验：
if (divisor == 0) { throw new IllegalArgumentException("除数不能为零"); } - 若发生在底层工具类（如自定义
MathUtils.divide(int, int)），建议返回Optional或抛出带语义的业务异常，而非暴露ArithmeticException - 日志记录时保留原始上下文：
log.warn("除法运算异常，a={}, b={}", a, b, e);，避免只记e.getMessage()
ArithmeticException和NullPointerException混用的坑
有些开发者会把空对象解包后的算术操作（如Integer a = null; int b = a + 1;）误认为触发ArithmeticException，实际抛的是NullPointerException——因为a + 1先触发自动拆箱（a.intValue()），而null.intValue()才抛空指针。
Integer a = null;
try {
int b = a + 1; // 这里抛 NullPointerException
} catch (ArithmeticException e) {
// 永远进不来
}
- 所有包装类型参与算术运算前都会拆箱，
null导致NullPointerException -
ArithmeticException只来自JVM字节码层面的idiv/irem指令失败 - 静态分析工具（如SpotBugs）能标记这类潜在
NullPointerException，但不会报ArithmeticException风险
性能与编译器优化的影响
ArithmeticException是运行时异常，JVM不会为它做特殊优化；但编译器可能在常量折叠阶段提前报错。例如：int x = 5 / 0;在编译期就会被javac拒绝，报error: division by zero。
立即学习“Java免费学习笔记（深入）”；
- 变量参与的除法（
int x = a / b;）一定在运行时检查，无法被JIT消除 - 使用
Objects.requireNonNull()等前置校验，比依赖异常处理更高效（异常创建开销大） - 在性能敏感路径（如游戏循环、实时计算），应避免用异常控制流程
ArithmeticException不是“数学错误”的通用兜底，它只覆盖极少数确定场景；而多数看似“算术问题”的异常，其实来自空值、类型转换或并发修改。 
