java整数除零强制抛arithmeticexception，因jvm规范定义其为未定义行为；浮点数遵循ieee 754返回infinity或nan；安全做法是运算前显式校验除数非零。
Java中除零为什么会抛出 ArithmeticException
因为整数类型（int、long、short、byte）在JVM规范中明确定义：除零是未定义行为，必须由虚拟机立即抛出 ArithmeticException。这不是可选的“警告”，而是强制语义——哪怕除数是变量、常量或编译期可推断的 0，运行时只要发生，就中断执行。
浮点数（float、double）例外：它们遵循IEEE 754标准，1.0 / 0.0 得到 Infinity，0.0 / 0.0 得到 NaN，不会抛异常。
- 检查除数是否为零不能只靠
if (divisor == 0)——如果divisor是Integer包装类，需先判空再解包 - 用
BigDecimal做精确计算时，divide()方法默认也抛ArithmeticException（非零除零），但可传入RoundingMode避免，例如：bigDec.divide(other, RoundingMode.HALF_UP) - 不要依赖
try-catch捕获ArithmeticException来“兜底”——它属于RuntimeException，掩盖逻辑缺陷，且性能开销明显
如何安全地做整数除法与取模运算
核心原则：所有可能为零的除数，必须在运算前显式校验；对用户输入、数据库字段、配置值等外部来源的数据，尤其不能假设“它不会是零”。
public static int safeDivide(int dividend, int divisor) {
if (divisor == 0) {
throw new IllegalArgumentException("divisor must not be zero");
}
return dividend / divisor;
}
public static int safeMod(int dividend, int divisor) {
if (divisor == 0) {
throw new IllegalArgumentException("divisor must not be zero");
}
return dividend % divisor;
}
-
%运算符和/一样，对整数零除数同样抛ArithmeticException - 注意负数场景：
-5 % 2结果是-1（Java取模符号跟随被除数），若业务需要非负余数，应手动调整：((a % b) + b) % b - 涉及循环索引或分页计算时（如
index % pageSize），确保pageSize初始化不为零——常见坑是配置未加载完成就执行计算
ArithmeticException 还会在哪些非除零场景出现
除零只是最常见原因，JDK中还有几处明确抛该异常，容易被忽略：
立即学习“Java免费学习笔记（深入）”；
-
BigInteger的divide()和remainder()方法：当除数为BigInteger.ZERO时抛出 -
Math.toIntExact(long)等溢出检查方法：当参数超出int范围时抛ArithmeticException（不是IllegalArgumentException） -
Arrays.setAll()或流操作中若 lambda 内部触发除零，异常堆栈会指向函数式接口调用点，定位成本更高 - JDBC驱动执行 SQL 时，某些数据库（如 PostgreSQL）返回数值错误（如除零、溢出），驱动可能包装为
SQLException，而非ArithmeticException——不能只捕获后者
用静态分析和单元测试提前拦截
靠人眼检查每处除法不可靠，尤其在复杂条件分支或重构后。推荐组合使用工具链：
- IDEA 或 Eclipse 启用 “Constant conditions & exceptions” 检查，能标出明显除零（如
x / 0）和冗余判空 - SpotBugs 规则
RV_DONT_JUST_NULL_CHECK_READLINE不相关，但ICAST_INTEGER_MULTIPLY_CAST_TO_LONG等溢出相关规则值得开启 - JUnit 测试必须覆盖边界值：
divisor = 0、Integer.MIN_VALUE / -1（整数溢出）、Long.MAX_VALUE + 1L（虽不抛 ArithmeticException，但结果错误） - 对关键计算模块（如计费、库存扣减），用
assert语句辅助开发期验证（注意-ea启动参数）：assert divisor != 0 : "divisor is zero in calcFee()";
真正难防的不是写错一行除法，而是把“不可能为零”的假设写进多层嵌套逻辑里，最后在某个配置开关关闭时才暴露——这类问题只能靠数据契约（如用 @NonNull + Checker Framework）和集成测试覆盖路径。
