在Java中如何获取异常详细信息_Java异常信息读取解析_网络技术

printStackTrace()直接输出异常调用栈到System.err，适合本地调试；getStackTrace()返回StackTraceElement[]供程序化分析；需用getCause()穿透嵌套异常获取根因，且注意getMessage()可能为null。

开发时最常用的调试方式，直接把异常的完整调用栈输出到标准错误流。它不返回字符串，而是立即打印，适合本地调试或日志不完善的场景。

注意：printStackTrace() 默认输出到 System.err，在某些容器或日志框架中可能被截断或丢失；生产环境不建议直接使用，应配合日志系统。

想重定向输出位置？传入 PrintStream 或 PrintWriter 参数，例如 e.printStackTrace(new PrintWriter(stringWriter))
只关心异常类型和消息？用 e.toString()，但会丢掉堆栈
需要结构化提取类名、行号？必须解析堆栈元素，不能靠字符串匹配

getStackTrace() 返回 StackTraceElement[]，每个元素包含类名、方法名、文件名和行号，是程序化分析异常路径的基础。

这个数组按“从抛出点到最外层调用”顺序排列，索引 0 就是异常最初发生的位置。

getMessage() 返回构造异常时传入的原始字符串，通常含技术细节（如 SQL 错误码、空指针字段名）；getLocalizedMessage() 本意是返回本地化消息，但多数 JDK 实现直接委托给 getMessage()，除非子类重写。

实际项目中，不要依赖 getLocalizedMessage() 做国际化，它不可靠。真正做多语言提示，应根据异常类型查资源包。

Java 异常链（如 new RuntimeException("wrap", cause)）中，根因往往藏在 cause 里。只看最外层异常的 message 和 stack trace，大概率错过真实问题。

尤其在 Spring、MyBatis 等框架中，业务异常常被包装成 RuntimeException，原始 SQLException 或 IOException 就在 getCause() 里。

安全获取根本原因：循环调用 getCause() 直到返回 null，但要防循环
引用（JDK 7+ 已处理）
Spring 提供了 org.springframework.util.ExceptionUtils.getRootCause()，可直接用
日志记录时，建议同时输出 e.getMessage() 和 e.getCause() != null ? e.getCause().getMessage() : "no cause"

异常信息不是越长越好，关键是要能快速区分「哪里出的错」「为什么出错」「谁该负责修」。堆栈深度、cause 链路、message 语义，这三者缺一不可——但最容易被忽略的，是假设 getCause() 一定非空，或者认为 getStackTrace() 总能拿到源码行号。