SQL触发器无法捕获运行时异常，仅能主动抛出校验错误；真正记录未捕获异常需依赖PL/pgSQL函数内EXCEPTION块（配合dblink异步写日志）、数据库级错误日志或应用层拦截。
SQL 触发器本身无法捕获运行时异常（如除零、主键冲突、类型转换失败等）——它不是 try/catch 机制，而是在 DML 事件发生时自动执行的代码块。真要记录未捕获异常，得靠数据库层的错误日志、存储过程封装 + 异常处理，或应用层兜底。
触发器里写 RAISE 或 INSERT 不等于“捕获异常”
很多人误以为在 BEFORE INSERT 触发器中加个 IF NEW.price < 0 THEN RAISE EXCEPTION 'price must be positive'; END IF; 就算“捕获了异常”。其实这只是主动抛出校验错误，属于业务逻辑前置拦截，并非捕获 SQL 执行过程中真正失控的运行时错误（比如 INSERT INTO t VALUES (1/0) 这种底层报错）。
关键点：
- 触发器执行期间若自身出错（如引用了不存在的列），整个事务会回滚，但你没机会“记录”这个错误——因为记录操作（比如
INSERT INTO error_log）也随事务一起回滚了 - PostgreSQL 的
EXCEPTION块只在PL/pgSQL函数/过程里有效，不能直接写在触发器函数外或普通 SQL 中 - MySQL 的触发器不支持异常处理语法（无
DECLARE HANDLER在所有版本中都受限，且仅对部分 SQLSTATE 生效）
真正能记录未捕获异常的可行路径
想让“语句执行崩了还能留下痕迹”，必须跳出触发器思维，改用有错误隔离能力的结构：
- 把业务 SQL 封装进
PL/pgSQL函数，在函数内用BEGIN ... EXCEPTION WHEN OTHERS THEN INSERT INTO error_log ...; RAISE NOTICE ...;捕获并落库（注意：INSERT需在EXCEPTION块里，且表需设为UNLOGGED或使用dblink异步写，否则仍可能因事务回滚而丢失日志） - 启用数据库级日志：PostgreSQL 设置
log_statement = 'all'或log_min_error_statement = error，配合log_destination = 'csvlog'输出结构化错误日志，再由外部工具采集分析 - 应用层统一拦截：在 JDBC/ODBC 层 catch
SQLException，提取getSQLState()和getMessage()，写入独立日志表（绕过数据库事务上下文） - 避免用触发器做兜底：例如在
AFTER INSERT里查刚插的数据再做复杂计算并写日志？一旦计算出错，整个 INSERT 就失败——这不是记录异常，是制造异常
PostgreSQL 示例：带错误隔离的日志记录函数
这是目前最贴近“运行时异常可记录”的实操方案（注意不是触发器）：
CREATE OR REPLACE FUNCTION safe_insert_with_logging(
p_id INT,
p_value TEXT
) RETURNS VOID AS $$
BEGIN
INSERT INTO main_table(id, value) VALUES (p_id, p_value);
EXCEPTION
WHEN OTHERS THEN
-- 使用 dblink 异步写日志，避免受主事务影响
PERFORM dblink_exec('host=localhost dbname=mydb',
'INSERT INTO error_log(error_time, sql_state, message) VALUES (now(), ''' || SQLSTATE || ''', ''' || SQLERRM || ''');');
RAISE NOTICE 'Logged error %: %', SQLSTATE, SQLERRM;
END;
$$ LANGUAGE plpgsql;调用时用 SELECT safe_insert_with_logging(1, 'test'); 而非直接 INSERT。这样即使插入失败，日志仍能落地。
真正棘手的是：错误日志表自己出问题（如磁盘满、权限丢）、dblink 连接失败、或异常发生在函数入口前（如参数类型根本无法转成 INT）。这些边界情况比“怎么写触发器”更值得花时间设计降级策略。
