MySQL函数中DECLARE CONTINUE HANDLER无法真正捕获异常并返回默认值，错误触发时函数直接终止，RETURN不执行；唯一可靠方式是前置校验+显式分支或主动SIGNAL SQLSTATE '45000'抛出自定义错误。
MySQL自定义函数中无法真正“捕获”异常并返回默认值——任何试图用 DECLARE CONTINUE HANDLER 实现容错返回的写法，都会在错误触发时直接中断函数，RETURN 不会执行，调用方收到的是原始 SQL 错误（如 ERROR 1329、ERROR 1452），而不是你预设的 NULL 或字符串。
为什么 CONTINUE HANDLER 在函数里不工作
很多人照搬存储过程的写法，在函数里写：
DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET @ret = NULL;
但实际效果是：一旦 SELECT ... INTO 查不到数据，函数立刻终止，@ret 不会被赋值，后续 RETURN @ret 根本不会运行。官方文档未承诺该语法在函数中的行为一致性，MySQL 5.7–8.0 各版本表现也不统一。
常见错误现象包括：
ERROR 1329 (02000): No data - zero rows fetched, selected, or processedERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails- 函数调用返回空结果或报错，而非你期望的
NULL或'N/A'
真正可行的替代方案：前置校验 + 显式分支
把“异常场景”转化为可判断的逻辑分支，避免让错误进入执行路径。这是唯一稳定、可控的方式。
使用场景包括：
- 查表取值（如根据 ID 获取名称）：用
EXISTS或COUNT(*)先判存，再查 - 除零风险：显式
IF y = 0 THEN RETURN NULL; - 数值转换：用
CAST(... AS SIGNED)前先REGEXP校验格式
示例：安全查学生姓名（防 ERROR 1329）
DELIMITER $$
CREATE FUNCTION sname_safe(a CHAR(10)) RETURNS CHAR(10)
READS SQL DATA
BEGIN
DECLARE s CHAR(10) DEFAULT NULL;
-- 先确认存在，避免 SELECT INTO 报错
IF EXISTS (SELECT 1 FROM student WHERE 学号 = a) THEN
SELECT 姓名 INTO s FROM student WHERE 学号 = a;
END IF;
RETURN s;
END$$
DELIMITER ;注意：EXISTS 必须走索引，否则性能陡降；别用 SELECT COUNT(*) > 0 替代。
想抛自定义错误？只能用 SIGNAL，不能“兜底”
如果你需要明确区分“业务异常”和“系统错误”，唯一可靠方式是主动 SIGNAL SQLSTATE '45000'，并由客户端捕获处理。
关键点：
-
SIGNAL必须出现在逻辑分支中，不能放在HANDLER里 - 必须配
SET MESSAGE_TEXT = 'xxx'，否则客户端看到的是空消息 - PHP PDO、Python
pymysql、Java JDBC 都能通过SQLSTATE拦截'45000' - 函数里
SIGNAL后的代码不会执行，所以它不是“返回默认值”，而是“中止并通知”
例如除零时拒绝计算，而非返回 NULL：
IF y = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '除数为零，无法计算'; END IF;
真正容易被忽略的是：函数设计边界。它不是存储过程，不支持事务、不能改数据、不能调用非确定性函数（如 NOW()）。所有“异常处理”的幻想，都源于把它当成了更通用的执行单元——而 MySQL 的函数就是纯计算黑盒，输入决定输出，出错就该提前挡住，而不是事后捞。
