error_number() 在 catch 块中返回错误号，范围外返回 null；必须在 catch 开头连续调用，嵌套时返回对应层级错误号，不可在其他数据库中直接类比使用。
SQL Server 中 ERROR_NUMBER() 和 ERROR_LINE() 必须在 CATCH 块内立即调用
这两个函数返回的值只在当前 BEGIN CATCH 块内有效，一旦执行了 RETURN、END CATCH 或任何可能中断控制流的语句，它们就清空了。很多人把 ERROR_LINE() 赋值给变量后，又在后面加了 IF @@TRANCOUNT > 0 ROLLBACK，结果日志里行号变成 NULL——就是因为中间夹了别的语句。
实操建议：
- 所有
ERROR_*()函数调用必须放在CATCH块最开头，且连续无间断 - 不要写成
SELECT ERROR_NUMBER(), ...后再插入日志表；先存变量，再统一处理 - 如果存储过程被嵌套调用，
ERROR_PROCEDURE()返回的是最内层出错的过程名，不是入口过程 -
ERROR_LINE()是 TRY 块内的相对行号，不是整个存储过程的绝对行号（比如 TRY 从第 50 行开始，报错在 TRY 内第 12 行，则返回 12）
PostgreSQL 里 SQLSTATE 和 GET STACKED DIAGNOSTICS 才能拿到真实行号
PostgreSQL 的 EXCEPTION 块不直接提供行号，ERROR_LINE() 这类函数根本不存在。想定位具体哪一行崩的，必须靠 GET STACKED DIAGNOSTICS 提取 v_context，再解析堆栈字符串——它包含类似 PL/pgSQL function test_proc() line 42 at INSERT 的信息。
实操建议：
- 在
EXCEPTION块开头立刻执行：GET STACKED DIAGNOSTICS v_context = PG_EXCEPTION_CONTEXT; - 不要依赖
SQLSTATE字符串本身带位置信息——它只告诉你错的类型（如'23505'），不告诉你在哪 - 若需结构化记录，用
regexp_matches(v_context, 'line (\d+)')提取数字，但注意上下文格式可能随版本微调 - 预定义条件（如
unique_violation）无法替代SQLSTATE '23505'的精确匹配，尤其在跨扩展或自定义错误时
Oracle 中 SQLCODE 和 FORMAT_ERROR_BACKTRACE() 才是真行号来源
SQLCODE 只返回错误号（如 -2291 表示外键违例），SQLERRM 是带前缀的文本，二者都不含行号。真正能定位到 PL/SQL 块内第几行出错的，只有 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE() ——它返回的是异常实际发生的物理行号，不是编译警告里的“第 X 行”。
实操建议：
- 必须在
EXCEPTION块中调用FORMAT_ERROR_BACKTRACE()，且不能放在WHEN OTHERS THEN NULL;后面 - 该函数不显示调用链，只返回当前块内位置；若想追溯到调用方，得手动拼接
$$PLSQL_UNIT和$$PLSQL_LINE - 编译期错误（如 PLS-00201）根本进不了
EXCEPTION块，得先跑show errors procedure your_proc_name; -
SQLCODE对NO_DATA_FOUND返回+100，不是负数，别拿它和 ORA 错误号直接比
MySQL 没有 ERROR_LINE()，靠 SHOW WARNINGS + 分段 EXECUTE 定位
MySQL 存储过程中没有内置行号函数，SHOW WARNINGS 也不返回位置信息。所谓“定位具体语句”，本质是人工切片：把动态 SQL 拼出来、把 IF 分支拆开、把循环体单独拎出，让每段都可独立验证。
实操建议：
- 在
EXECUTE前加SELECT @sql AS debug_sql;，复制输出结果到新窗口执行——90% 的引号/反引号/变量拼接问题当场暴露 -
SHOW WARNINGS必须紧跟在出错语句之后执行，延迟哪怕一条空语句，信息就丢失 - 避免在
IF块内声明变量后，在ELSE里引用；作用域错乱会导致“找不到变量”这类伪行号错误 - 对含
DECLARE CONTINUE HANDLER的场景，错误捕获发生在语句级，不是过程级，别指望它告诉你哪一行
ERROR_LINE() 逻辑直接套到 PostgreSQL 或 Oracle 上，结果查半天日志发现字段全为 NULL 或压根不存在。
