能，但仅限after触发器且兼容级别≥90；try catch无法捕获编译期错误、终止性错误（如外键/唯一约束冲突）、严重性≤10的警告及导致连接关闭的严重性≥20错误，raiserror若未设正确级别也绕过catch。
SQL Server触发器里TRY CATCH能用吗
能，但必须是 AFTER 触发器（不能是 INSTEAD OF），且数据库兼容级别 ≥ 90（即 SQL Server 2005+）。TRY CATCH 在触发器中生效的前提是：异常发生在 TRY 块内，且该异常未被上层（比如调用 INSERT/UPDATE/DELETE 的客户端）提前截断。
为什么直接写TRY CATCH可能没反应
常见原因是触发器抛出的错误类型不进入 CATCH 块。以下几类错误会“绕过” TRY CATCH，直接终止批处理：
-
RAISERROR级别 - 编译期错误（如表名错、语法错）——根本不会运行到 TRY 块
- 严重级别 ≥ 20 的致命错误（如资源耗尽、连接中断）
- 某些 DDL 操作引发的错误（如在触发器里建表失败）
真正能被捕获的，主要是运行时错误：除零、主键冲突、外键约束失败、转换失败（如 CONVERT(int, 'abc')）、空值插入非空列等。
如何可靠记录触发器自身异常
关键不是“捕获后继续执行”，而是“捕获后把上下文写进日志表，再显式抛出或静默吞掉”。推荐做法：
- 建一张专用日志表，字段至少含：
log_id、trigger_name、error_number、error_message、error_severity、error_state、error_line、inserted_count、deleted_count、log_time - 在
CATCH块中用INSERT INTO log_table ... SELECT ...记录ERROR_*()函数返回值 - 慎用
THROW或RAISERROR向外抛错 —— 若业务逻辑依赖触发器成功完成，建议抛出带明确提示的错误（如THROW 50001, 'Trigger failed: %s', 1） - 避免在
CATCH里再做复杂操作（如调用存储过程、连外部服务），以防二次失败导致日志丢失
示例片段：
BEGIN TRY
INSERT INTO audit_log (...)
SELECT ..., GETDATE() FROM inserted;
END TRY
BEGIN CATCH
INSERT INTO trigger_error_log (
trigger_name, error_number, error_message,
error_severity, error_state, error_line, log_time
) VALUES (
N'trg_after_insert_orders',
ERROR_NUMBER(),
ERROR_MESSAGE(),
ERROR_SEVERITY(),
ERROR_STATE(),
ERROR_LINE(),
GETDATE()
);
THROW; -- 重新抛出，让调用方知道出错了
END CATCH
触发器嵌套和事务的影响
如果触发器里修改了另一张也带触发器的表，就可能触发嵌套。此时 TRY CATCH 只捕获当前层级的错误，外层触发器的 CATCH 不会感知内层失败，除非内层显式 THROW 或事务被回滚。
- 所有触发器运行在同一个隐式事务中（由原始 DML 启动）
- 任一触发器内
THROW或未捕获错误 → 整个事务回滚 → 所有已做的变更（包括其他触发器里的）都会撤销 - 若想“局部失败不影响整体”，必须用
SAVE TRANSACTION+ROLLBACK TO，但极不推荐 —— 触发器语义本就是强一致性保障，绕开它容易破坏数据完整性
真正难处理的是：日志表本身插入失败。这时候连错误都记不下来。稳妥做法是把日志表设计为最简结构（无外键、无计算列、无触发器），并确保其所在文件组空间充足。
