SQL错误处理的重要性
在数据库开发过程中，我们写的SQL语句往往不是只运行一次就结束，很多时候会被封装成存储过程、函数，或者嵌入到应用程序的业务逻辑里反复调用。如果只写正常执行的逻辑，一旦遇到异常场景，比如插入数据时违反了唯一约束，或者查询时引用的表不存在，数据库就会直接抛出错误，导致整个操作流程中断，甚至可能造成事务回滚不及时、数据残留等问题。防御性编程的核心就是要提前考虑各种可能出现的异常情况，通过错误处理函数把风险降到最低，提升代码的健壮性和容错能力。
常见数据库的错误处理函数与用法
MySQL的SIGNAL和RESIGNAL
MySQL从5.5版本开始支持SIGNAL语句，用来主动抛出自定义的错误，我们可以在存储过程里结合条件判断来使用它。当检测到不符合预期的情况时，用SIGNAL返回明确的错误码和错误信息，让调用方知道具体出了什么问题。
DELIMITER //
CREATE PROCEDURE insert_user(IN user_name VARCHAR(50), IN user_age INT)
BEGIN
-- 先判断年龄是否合法
IF user_age < 0 OR user_age > 150 THEN
-- 主动抛出错误，错误码自定义，错误信息清晰描述问题
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '用户年龄必须在0到150之间';
END IF;
-- 正常插入逻辑
INSERT INTO user_info (name, age) VALUES (user_name, user_age);
END //
DELIMITER ;如果需要在捕获到已有错误后重新抛出，或者修改错误信息再抛出，可以使用RESIGNAL语句，它和SIGNAL的用法类似，但是只能在异常处理块里使用。
SQL Server的TRY CATCH结构
SQL Server提供了类似编程语言的TRY CATCH块来捕获异常，把可能出现错误的代码放在TRY块里，错误处理逻辑放在CATCH块里，同时可以通过系统函数获取错误的详细信息。
CREATE PROCEDURE update_user_balance
@user_id INT,
@change_amount DECIMAL(10,2)
AS
BEGIN
BEGIN TRY
BEGIN TRANSACTION;
-- 更新用户余额
UPDATE user_account
SET balance = balance + @change_amount
WHERE id = @user_id;
-- 如果更新后余额为负数，主动抛错
IF (SELECT balance FROM user_account WHERE id = @user_id) < 0
BEGIN
THROW 50001, '用户余额不足，无法完成操作', 1;
END
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
-- 回滚事务，避免数据不一致
IF @@TRANCOUNT > 0
ROLLBACK TRANSACTION;
-- 打印错误信息，实际场景中可以记录到日志表
SELECT
ERROR_NUMBER() AS 错误码,
ERROR_MESSAGE() AS 错误信息,
ERROR_LINE() AS 错误行号;
END CATCH
END;PostgreSQL的EXCEPTION块
PostgreSQL在PL/pgSQL的存储过程或函数里，通过BEGIN END块结合EXCEPTION子句来捕获异常，支持捕获特定类型的异常，也可以捕获所有异常。
CREATE OR REPLACE FUNCTION delete_user(IN user_id INT)
RETURNS TEXT AS $$
DECLARE
result TEXT;
BEGIN
BEGIN
DELETE FROM user_info WHERE id = user_id;
-- 如果没有找到要删除的用户，这里不会报错，需要手动判断
IF NOT FOUND THEN
result := '未找到对应用户';
ELSE
result := '用户删除成功';
END IF;
EXCEPTION
WHEN foreign_key_violation THEN
result := '该用户存在关联数据，无法删除';
WHEN OTHERS THEN
result := '删除用户时发生未知错误: ' || SQLERRM;
END;
RETURN result;
END;
$$ LANGUAGE plpgsql;用错误处理实现防御性编程的技巧
提前校验输入参数
很多SQL错误都是因为输入参数不合法导致的，比如传入的字符串长度超过字段限制，或者数值超出范围。在存储过程或者函数的开头，先对输入参数做校验，不合法的直接通过错误处理函数返回提示，不要等到执行SQL语句时才报错，这样能更早发现错误，减少不必要的数据库操作。
事务中合理使用错误处理
当操作涉及多条SQL语句，并且需要保证原子性的时候，一定要把操作放在事务里，同时在错误处理里加上事务回滚的逻辑。如果执行过程中出现异常，第一时间回滚事务，避免部分语句执行成功、部分失败，导致数据不一致。比如上面的SQL Server例子里，CATCH块里就判断了是否存在未提交的事务，有的话就回滚。
记录错误日志便于排查
捕获到错误之后，除了返回错误信息给调用方，最好把错误的详细信息记录到专门的错误日志表里，包括错误发生的时间、存储过程名称、输入参数、错误码、错误信息等。这样后续排查问题的时候，不需要去翻数据库的日志，直接查日志表就能快速定位问题原因。
-- 以MySQL为例的错误日志表结构
CREATE TABLE sql_error_log (
id INT PRIMARY KEY AUTO_INCREMENT,
procedure_name VARCHAR(100),
input_params TEXT,
error_code VARCHAR(50),
error_message TEXT,
occur_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- 在存储过程的错误处理块里插入日志
DECLARE v_error_msg TEXT;
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
BEGIN
GET DIAGNOSTICS CONDITION 1
v_error_msg = MESSAGE_TEXT;
INSERT INTO sql_error_log (procedure_name, input_params, error_message)
VALUES ('insert_user', CONCAT('name:', user_name, ',age:', user_age), v_error_msg);
END;避免吞掉异常
有些开发者在写错误处理的时候，为了不让程序报错，会把所有异常都捕获，但是不做任何处理，或者直接返回一个笼统的成功提示，这样会让调用的上层误以为操作成功，实际上可能已经出错了。防御性编程要求错误处理要透明，要么把明确的错误信息返回给调用方，要么在确认不影响核心逻辑的情况下做降级处理，并且记录日志，绝对不能悄悄忽略异常。
常见错误处理的误区
- 只在最外层做错误处理：如果存储过程内部调用了其他存储过程，只在最外层捕获错误，可能会丢失内部的具体错误信息，最好每一层都做必要的错误处理，再把错误往上抛。
- 过度使用自定义错误：有些场景数据库本身的错误提示已经很清晰，不需要再额外自定义错误，过度自定义反而会增加维护成本，只有那些业务层面的校验错误，才需要自定义错误信息。
- 错误处理里再写可能出错的SQL：如果在CATCH或者EXCEPTION块里写插入日志之类的SQL，但是没有给这段逻辑加错误处理，那么日志插入失败的时候，可能会导致整个错误处理流程也出错，所以日志插入最好用单独的逻辑，或者保证日志插入不会失败。
不同场景的最佳实践
如果是简单的查询语句，不需要复杂的错误处理，但是涉及到数据修改（增删改）的操作，尤其是多表关联修改、批量操作的时候，一定要加上完整的错误处理和事务控制。如果是供外部系统调用的存储过程，错误信息的返回要友好，不要用数据库内部的错误码，而是转换成业务能理解的错误提示。如果是定时任务里执行的SQL脚本，错误处理要加上邮件或者告警通知，一旦出错能及时告知运维人员。
通过合理使用SQL的错误处理函数，结合防御性编程的思路，我们写的SQL代码就能应对更多异常场景，减少线上故障的发生，也让后续的维护工作变得更轻松。不同的数据库虽然错误处理的语法有差异，但是核心思路都是提前预判风险、捕获异常、合理处理、记录信息，只要掌握了这个核心，就能写出更健壮的SQL代码。