PL/SQL中ZERO_DIVIDE异常必须显式捕获，它在运行时触发且无法被SQL层条件过滤；需在BEGIN...EXCEPTION块中用WHEN ZERO_DIVIDE THEN处理，不可依赖视图或内联视图隐藏除零。
PL/SQL 中 ZERO_DIVIDE 异常必须显式捕获，不能靠 SQL 层过滤
除零在 pl/sql 里不会静默返回 null 或 inf，而是立刻抛出 zero_divide 异常并中断执行。哪怕你在 select 里用 decode 或 case 判断分母是否为 0，只要实际执行到除法运算（比如赋值、return、insert values），异常就触发——sql 层的条件判断拦不住 pl/sql 运行时的除零检查。
常见错误现象：ORA-01476: divisor is equal to zero 直接报出，没进 EXCEPTION 块，说明你把除法写在了 SELECT ... INTO 的查询体里，而没在 PL/SQL 块级做保护。
- 把除法逻辑移到 PL/SQL 变量计算中，再用
IF denominator != 0 THEN ... ELSE ... END IF;预检 - 或确保除法只出现在可被
EXCEPTION捕获的语句位置（如赋值、函数调用） - 不要依赖视图或内联视图隐藏除零——PL/SQL 调用时照样崩
EXCEPTION 块里捕获 ZERO_DIVIDE 的标准写法
Oracle 预定义了 ZERO_DIVIDE 异常，不需要 PRAGMA EXCEPTION_INIT 绑定，直接在 EXCEPTION 后用 WHEN ZERO_DIVIDE THEN 即可。但要注意：它只捕获「纯除零」，不捕获 NULL 参与的运算（比如 10 / NULL 结果是 NULL，不抛异常）。
使用场景：封装计算函数、过程内数值转换、报表数据加工等需要稳定返回值的地方。
- 必须写在 PL/SQL 块的
EXCEPTION区域，不能放在匿名块外或子程序外 - 若同时处理多个异常，
WHEN ZERO_DIVIDE应靠前，避免被WHEN OTHERS吞掉 - 示例：
DECLARE<br> v_result NUMBER;<br>BEGIN<br> v_result := 100 / :user_input;<br>EXCEPTION<br> WHEN ZERO_DIVIDE THEN<br> v_result := 0; -- 或 RAISE_APPLICATION_ERROR(-20001, '除数不能为零');<br>END;
和 VALUE_ERROR 混淆的典型坑
当除数是字符串类型（如 VARCHAR2）且内容为 '0'，而你又没显式 TO_NUMBER()，运行时可能先抛 VALUE_ERROR（转换失败），而不是 ZERO_DIVIDE。只有成功转成数字后的除零才触发后者。
容易踩的坑：
- 参数传入的是字符串，却直接用于除法：
v_num := p_input / 10;→ 先转类型失败，不是除零问题 - 用了
TO_NUMBER(p_input)但没包VALUE_ERROR，导致ZERO_DIVIDE根本没机会触发 - 在函数中返回
NUMBER，但调用方传了空字符串或非数字字符，异常类型对不上
性能与兼容性：ZERO_DIVIDE 捕获本身无开销，但逻辑分支要提前想清楚
异常处理机制在 Oracle 里是高效的，WHEN ZERO_DIVIDE 不会拖慢正常流程。真正影响性能的是你如何应对——比如在循环里频繁除零后做复杂回退，或者每次异常都查表记录日志。
兼容性方面：ZERO_DIVIDE 自 Oracle 7 起就存在，所有版本一致，无需适配。但注意：在 SQL 函数（如 WITH FUNCTION）中，异常行为和匿名 PL/SQL 块略有差异，某些上下文下可能无法捕获，建议坚持用标准 DECLARE ... BEGIN ... EXCEPTION 结构。
最易被忽略的一点：除零异常只发生在「运行时」，编译期完全检查不出来。哪怕你写了 IF v_denom = 0 THEN ...，如果这个变量来自用户输入或动态 SQL，静态分析也帮不了你——得靠测试覆盖边界值。
