SQL Server存储过程中RAISERROR不抛异常主因是SET XACT_ABORT OFF需在CREATE/ALTER PROC开头显式设为ON并配合TRY...CATCH与THROW使用验证逻辑须前置且原子化。存储过程里 RAISERROR 不抛出异常检查 SET XACT_ABORTSQL Server 存储过程中加了 RAISERROR但调用方没收到错误、事务也没回滚——大概率是 SET XACT_ABORT 关着的。默认它为 OFF此时某些错误比如约束冲突会中断当前批处理但不会让整个事务自动回滚RAISERROR 也常被上层静默吞掉。SET XACT_ABORT ON 必须在 CREATE PROC 或 ALTER PROC 开头显式设置不能只在执行时 SET它影响的是“语句级错误是否终止事务”和 THROW 行为不完全等价SQL Server 2012 推荐优先用 THROW但老过程混用 RAISERROR 时更得盯紧这个开关验证方法在过程开头加 SELECT XACT_ABORT FROM sys.dm_exec_sessions WHERE session_id SPID确认值为 1用 ERROR 做断言别信它改用 TRY...CATCH ERROR_NUMBER()ERROR 只保留上一条语句的错误号且一查就清零。在多语句逻辑里插 IF ERROR 0极易漏判——尤其中间夹了 SELECT、SET 这类“无错必过”的语句ERROR 就被覆盖了。所有关键操作如 UPDATE、INSERT必须包在 TRY 块里CATCH 中用 ERROR_NUMBER()、ERROR_MESSAGE() 拿真实上下文不要在 CATCH 里只写 RETURN得显式 THROW 或 RAISERROR否则调用链根本不知道出错了注意嵌套存储过程里外层 TRY 捕不到内层未 THROW 的错误必须逐层透传或统一用 THROW无参数重抛数据验证逻辑放哪别塞在最后要卡在变更前常见反模式先 UPDATE再查 IF NOT EXISTS (SELECT ...) 判失败。这会导致脏写——数据已改断言却晚一步修复成本陡增。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。