Oracle触发器中捕获ZERO_DIVIDE异常需在BEGIN...END块内用EXCEPTION WHEN ZERO_DIVIDE THEN处理，不可省略；必须显式捕获，否则导致DML回滚，且仅允许一个EXCEPTION块，推荐写入日志表而非仅用DBMS_OUTPUT。
Oracle触发器里怎么捕获 ZERO_DIVIDE 异常
Oracle 触发器中遇到除零不会静默忽略，而是直接抛出预定义异常 ZERO_DIVIDE，必须显式捕获，否则整个 DML 语句会回滚失败。
触发器本身没有独立事务上下文，异常不处理就会向上冒泡到调用它的 INSERT/UPDATE/DELETE 语句，导致操作中断。所以不能靠外围逻辑兜底，必须在触发器内部 EXCEPTION 块里接住。
- 必须把可能触发除法的语句（比如
:new.amount / :new.quantity）放在BEGIN...END执行块内，不能写在声明区或直接裸写 -
EXCEPTION部分只能跟在BEGIN后，且一个触发器只允许一个EXCEPTION块 - 捕获后建议用
DBMS_OUTPUT.PUT_LINE记日志（仅调试），生产环境更推荐写入自定义日志表，避免依赖客户端输出开关
示例：
CREATE OR REPLACE TRIGGER check_cvr
BEFORE INSERT ON orders
FOR EACH ROW
DECLARE
v_ratio NUMBER;
BEGIN
v_ratio := :new.revenue / NULLIF(:new.units, 0); -- 先用 NULLIF 防硬错
:new.cvr := ROUND(v_ratio * 100, 2);
EXCEPTION
WHEN ZERO_DIVIDE THEN
:new.cvr := 0;
INSERT INTO trigger_log VALUES (SYSDATE, 'ZERO_DIVIDE in check_cvr', :new.order_id);
END;SQL Server 触发器中用 TRY...CATCH 捕获除零
SQL Server 不提供命名异常，ZERO_DIVIDE 这类错误统一归为运行时错误，错误号是 8134。必须用 TRY...CATCH 结构包裹风险语句，不能靠 ISNULL 或 NULLIF 完全规避——因为某些表达式（如聚合后除法）仍可能在运行时崩。
-
TRY块里放计算逻辑，CATCH块里用ERROR_NUMBER()判断是否为8134 - 触发器中禁止使用
RETURN或RAISERROR中断流程（除非你真想让整个 DML 失败），应优先设默认值并继续执行 - 注意：SQL Server 触发器默认是
AFTER类型，若改用INSTEAD OF，需确保CATCH里手动补上原意欲执行的 INSERT/UPDATE 逻辑，否则数据不会落库
示例：
CREATE TRIGGER trg_calc_rate ON sales AFTER INSERT AS BEGIN DECLARE @numerator DECIMAL(10,2), @denominator INT, @rate DECIMAL(5,2); <p>SELECT @numerator = SUM(amount), @denominator = COUNT(*) FROM inserted;</p><p>BEGIN TRY SET @rate = @numerator / NULLIF(@denominator, 0); END TRY BEGIN CATCH IF ERROR_NUMBER() = 8134 SET @rate = 0; END CATCH</p><p>UPDATE s SET conversion_rate = @rate FROM sales s INNER JOIN inserted i ON s.id = i.id; END
为什么不能只靠 NULLIF 就完事
NULLIF(denom, 0) 确实能把 0 转成 NULL，让除法结果变成 NULL 而非报错，但它只解决“语法安全”，不解决“业务含义模糊”问题。
- 当分母本该非零却为 0（比如上游漏传、ETL 错误），返回 NULL 可能掩盖数据质量问题，而捕获异常后可以记录上下文、告警或走降级逻辑
- 某些数据库（如旧版 PostgreSQL）对
NULLIF在窗口函数或子查询中的行为不一致，异常捕获是更底层、更可控的兜底手段 - 触发器里如果涉及多步计算（比如先算比率再查码表映射等级），除零只是第一道关卡；后续步骤可能因前面返回 NULL 导致
NO_DATA_FOUND或空指针类错误，需要分层捕获
跨数据库兼容性要注意的点
MySQL 触发器根本不支持异常处理语法（无 EXCEPTION、无 TRY CATCH），遇到除零直接报错终止。此时唯一办法是前置防御：所有除法前强制用 CASE WHEN denominator = 0 THEN ... ELSE ... END 或 IF(denominator = 0, 0, numerator/denominator)。
- PostgreSQL 支持
EXCEPTION块，但语法和 Oracle 不同：必须用RAISE NOTICE或RAISE EXCEPTION显式抛出，且不能在普通 SQL 触发器函数外用 - SQLite 完全没异常机制，也无
NULLIF，只能靠IIF(denom = 0, 0, num/denom)+ 类型强转（如CAST(num AS REAL)）保浮点精度 - 别忘了检查触发器执行时机：
BEFORE可修改:new值，AFTER只能查或更新其他表，异常处理策略得跟着变
真正难的不是写个 WHEN ZERO_DIVIDE THEN，而是想清楚：这个 0 是脏数据、配置缺失，还是合理边界值？捕获之后，是填 0、填 NULL、跳过整行，还是发告警？这些决策藏在异常分支里，而不是语法里。
