mysql函数中无法用declare handler捕获除零错误，唯一可靠方式是主动用if判断后signal sqlstate '45000'抛出自定义错误，客户端需识别该sqlstate处理。
MySQL自定义函数中无法安全捕获除零错误——它根本不会触发可捕获的异常，而是直接报错中断执行。 你不能像在存储过程中那样用 DECLARE CONTINUE HANDLER 拦截 ERROR 1365 (ER_DIVISION_BY_ZERO)，因为函数里该 HANDLER 不生效或行为不可靠。唯一可控、客户端可识别的处理方式，是**主动预防 + 主动抛出**。
为什么 DECLARE HANDLER 在函数里基本失效
很多人写完 DECLARE CONTINUE HANDLER FOR SQLEXCEPTION 就以为能兜底，但实际运行会发现：一旦执行到 RETURN x / y 且 y = 0，函数立即终止，RETURN 不执行，HANDLER 里的逻辑也不执行，调用方收到的是原始错误 ERROR 1365: Division by zero，不是你预设的值或提示。
-
DECLARE CONTINUE HANDLER在函数中语法虽合法，但官方未保证其稳定性；不同 MySQL 版本（尤其是 5.7 vs 8.0+）表现不一致 - 函数设计定位是“确定性计算单元”，不支持事务、不支持 EXIT/CONTINUE 的可靠上下文切换
- 试图用
SET @ret = NULL; RETURN @ret绕过，仍会在 HANDLER 触发前因除零错误退出
正确做法：用 IF + SIGNAL 主动防御
必须把“是否为零”的判断提到除法操作之前，在逻辑分支明确处拦截并中断，用 SIGNAL SQLSTATE '45000' 抛出自定义错误。这是唯一能让客户端（PHP PDO、Python pymysql、Java JDBC）拿到可识别错误码和语义化信息的方式。
- 检查必须在
RETURN前完成，例如：IF y = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '除数不能为零'; END IF; -
MESSAGE_TEXT必须显式设置，否则客户端看到的是空消息或乱码 - 不要在
SIGNAL前做全表扫描类操作（如无索引字段的EXISTS），否则错误没抛出，性能先崩了 - 函数体中禁止出现
INSERT/UPDATE/NOW()等非确定性语句，否则连创建都会失败（ERROR 1418）
NULLIF 只适用于查询语句，不解决函数内除零
NULLIF(denominator, 0) 是 SQL 查询层防除零的利器，但它在函数体内依然会触发除零错误——因为函数执行时，numerator / NULLIF(denominator, 0) 这个表达式本身在 denominator = 0 时求值为 numerator / NULL，结果是 NULL，看似安全。但注意：这只是“结果为 NULL”，不代表“没发生除零”；如果后续逻辑依赖该结果做非空判断或聚合，语义可能错位。
-
NULLIF不是异常处理机制，它只是值替换工具，无法替代逻辑校验 - 若业务要求“除数为 0 时返回特定默认值（如 -1 或 999）”，
NULLIF就必须配合COALESCE或CASE，而这些在函数里又得重写一遍判断逻辑 - 真正健壮的函数，应该覆盖
denominator IS NULL、ABS(denominator) 等边界，仅判 <code>= 0不够
客户端必须识别 SQLSTATE '45000' 才算闭环
服务端用了 SIGNAL，但 PHP 不检查 $pdo->errorCode()，Java 不 catch SQLState = 45000，那整个设计就白做了。错误还是裸露给终端用户。
- PHP PDO 示例：
if ($pdo->errorCode() === '45000') { echo $pdo->errorInfo()[2]; } - Python pymysql 示例：
except pymysql.err.IntegrityError as e: if e.args[0] == 1644: ... # 1644 是 SIGNAL 对应的 MySQL 错误号 - JDBC 示例：
if ("45000".equals(sqlex.getSQLState())) { ... }
最易被忽略的一点：函数里没有“降级返回”这回事——要么算出结果，要么明确中断。想靠 HANDLER 返回默认值，只会让错误更隐蔽、更难调试。
