FORMAT_ERROR_BACKTRACE是唯一能定位原始行号的函数，因其输出包含异常最初抛出位置的完整调用链（如“at 'SCOTT.PROC_INSERT', line 2”），而SQLERRM和FORMAT_ERROR_STACK仅返回笼统错误信息且不含行号。
必须在 EXCEPTION 块中调用 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE，且必须放在第一行；只用 SQLERRM 或 FORMAT_ERROR_STACK 无法定位到具体哪一行出错。
为什么 FORMAT_ERROR_BACKTRACE 是唯一能定位原始行号的函数
Oracle 报错时，SQLERRM 只返回类似 ORA-01403: no data found 这种笼统信息，不带位置；DBMS_UTILITY.FORMAT_ERROR_STACK 也等价于 SQLERRM，只描述错误本身。真正包含调用链和行号的是 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE，它输出形如：
ORA-06512: at "SCOTT.PROC_INSERT", line 2 ORA-06512: at "SCOTT.PKG_UTILS", line 45 ORA-06512: at line 1
首行就是异常最初抛出的位置——这是调试唯一可信的起点。
- 它依赖 PL/SQL 异常上下文，脱离
EXCEPTION块调用会返回NULL - 不能在异常未发生时提前调用（比如放在
BEGIN开头） - 每次异常抛出都会重置内部栈，所以必须在捕获后立刻读取
常见错误：调用顺序和环境配置导致堆栈丢失
以下写法会让 FORMAT_ERROR_BACKTRACE 返回空或错误堆栈被污染：
- 在
WHEN OTHERS THEN里先做ROLLBACK、赋值变量或写日志表，再调用它——任何前置操作都可能覆盖原始栈 - 调用后又执行
RAISE——这会重置堆栈，导致输出变成RAISE所在行，而非原始错误点 - 没在客户端开启
SET SERVEROUTPUT ON，导致DBMS_OUTPUT.PUT_LINE看不到输出 - 用 JDBC/ODP.NET 调用时，没显式调用
DBMS_OUTPUT.GET_LINES获取缓冲内容
正确写法示例：
BEGIN
INSERT INTO t VALUES (1);
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_BACKTRACE);
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
RAISE; -- 若需继续向上抛，放最后
END;
12c+ 推荐改用 UTL_CALL_STACK，但注意兼容性
UTL_CALL_STACK 在 Oracle 12c 引入，比 DBMS_UTILITY 系列更结构化，支持逐层读取调用信息（如 UNIT_LINE, OWNER, UNIT_NAME），适合封装成通用日志过程。
- 它不依赖异常上下文，可在任意位置调用（包括正常流程中），但要获取「错误源头」仍需配合异常处理逻辑
-
FORMAT_ERROR_BACKTRACE仍是最简、最直接、向后兼容性最好的方式，尤其在线上环境快速排障时 - 若项目已全面升级到 12c+ 且需要定制化堆栈分析（比如过滤系统包、提取特定层级），再考虑迁移
真正容易被忽略的是：堆栈信息只在异常刚被捕获那一瞬间有效，且仅对当前 PL/SQL 单元可见。跨包调用时，如果中间某层用了裸 WHEN OTHERS THEN NULL，原始堆栈就彻底断了——这不是函数的问题，是异常传递链被人为截断了。
