mysql函数中declare handler无效，异常触发即终止；唯一可控方式是前置校验后用signal sqlstate '45000'主动抛出带message_text的错误，函数仅支持纯计算，复杂逻辑应移至存储过程。
MySQL函数中无法捕获运行时异常，DECLARE HANDLER在函数里形同虚设——它语法上合法，但一旦触发（比如SELECT ... INTO查不到数据），函数直接终止，RETURN不会执行，调用方拿到的是原始错误（如ERROR 1329），不是你预设的逻辑分支。
函数里 DECLARE CONTINUE HANDLER 实际无效
很多人试图用DECLARE CONTINUE HANDLER FOR NOT FOUND兜底返回NULL，但实测在函数中完全不可靠：
- MySQL 8.0+ 中该 handler 触发后函数仍会立即退出，不执行后续语句
- 不同小版本行为不一致，官方文档未承诺其在函数中的稳定性
- 即使写成
SET @ret = NULL; RETURN @ret;，也会在 handler 执行前因错误中断 - 根本原因：函数设计定位是“纯计算单元”，不支持异常恢复语义
SIGNAL SQLSTATE '45000' 是唯一可控出口
必须主动抛出、不可依赖捕获。所有需要报错的逻辑分支，都得提前判断并显式SIGNAL：
- 错误码必须用
SQLSTATE '45000'（用户定义异常），不能只写SIGNAL SQLSTATE 'HY000' -
SET MESSAGE_TEXT = 'xxx'必须紧随SIGNAL后，否则客户端看到的是空消息或乱码 - 示例：防除零
DELIMITER $$
CREATE FUNCTION divide_safe(x DECIMAL(10,2), y DECIMAL(10,2)) RETURNS DECIMAL(10,2)
BEGIN
IF y = 0 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '除数不能为零';
END IF;
RETURN x / y;
END$$
DELIMITER ;
调用时客户端（如 Python pymysql、Java JDBC）能准确捕获 SQLSTATE 和自定义文本。
别把函数当存储过程用
函数里任何隐式或显式的副作用操作都会直接报错，且无法被SIGNAL覆盖：
- 禁止含
INSERT/UPDATE/DELETE—— 直接报ERROR 1418 - 禁止调用非确定性函数，如
NOW()、RAND()、UUID() - 禁止显式事务控制（
START TRANSACTION、COMMIT） - 避免在判断前做全表扫描（如无索引字段的
EXISTS），否则性能问题比报错更早暴露
真正需要异常捕获和事务回滚的逻辑，应该挪到存储过程中——那里DECLARE EXIT HANDLER FOR SQLEXCEPTION才稳定有效。函数只负责“输入→输出”，异常只能靠前置校验+主动中断来表达。最容易被忽略的是：哪怕你写了 handler，只要函数体里出现一条没兜住的 SELECT ... INTO，整个调用就崩了，连日志都留不下。
