异常信息必须包含上下文，不能只抛 new RuntimeException("出错")；应拼入关键变量、状态或输入值，并用带 cause 的构造函数保留原始堆栈；日志级别需匹配异常性质，WARN 用于业务校验失败，ERROR 用于系统级故障。
异常信息必须包含上下文，不能只抛 new RuntimeException("出错")
Java里最常犯的错误是用空泛字符串构造异常，比如 throw new IllegalArgumentException("参数错误")。这种写法在日志里完全无法定位问题：哪个方法？传了什么值？执行到哪一行？
正确做法是在消息中拼入关键变量、状态或输入值，例如：
throw new IllegalArgumentException("userId 为 null，调用方: " + Thread.currentThread().getStackTrace()[1].getMethodName());
更稳妥的方式是用 String.format 或现代 Java 的文本块 + 字符串拼接，避免空指针或格式错乱。注意别把敏感字段（如密码、token）打到日志里。
用 initCause() 或构造函数链式包装异常，保留原始堆栈
捕获异常后直接 throw new RuntimeException("xxx") 会丢失原始异常的堆栈和类型，导致无法判断是 NPE、SQLTimeout 还是网络中断。
立即学习“Java免费学习笔记（深入）”；
应该用带 cause 的构造函数，例如：
catch (SQLException e) {
throw new ServiceException("查询用户失败，sqlId=" + sqlId, e);
}
或者显式调用 initCause()（仅限无对应构造函数的老异常类）。这样日志打印时能展开 Cause by: 链，IDE 调试时也能逐层点开。
常见陷阱：
- 误用
e.printStackTrace()替代日志记录 —— 它输出到System.err，不走日志框架，无法集中收集 - 在
catch块里吞掉异常又不 re-throw —— 表面“安静”，实则掩盖故障
日志级别与异常类型要匹配，ERROR 不等于所有异常都打 ERROR
不是所有异常都需要 logger.error()。比如用户输入邮箱格式错误，抛 IllegalArgumentException，属于预期内校验失败，用 logger.warn() 更合适；而数据库连接池耗尽导致 SQLException 才该标 ERROR。
建议按异常性质分级：
-
WARN：业务校验失败、第三方接口返回非成功码但可重试 -
ERROR：系统级故障（DB down、RPC 超时、配置加载失败） -
FATAL（慎用）：JVM 级崩溃、磁盘满导致日志无法写入
同时确保日志语句里包含 e 参数，例如 logger.error("处理订单失败", e)，否则堆栈不会输出。
调试时优先看 getCause() 和 getStackTrace()，别只盯着第一行
IDE 调试时，异常变量展开后第一行往往是包装层（如 ServiceException），真正的问题往往藏在 cause 字段里。断点停住后，手动调用 e.getCause().getCause() 可能直达原始异常（比如 NullPointerException）。
如果用 Logback 或 Log4j2，启用 %ex{full} 或 %xEx 输出完整嵌套堆栈；默认的 %ex 可能只截断显示首层。
一个容易被忽略的细节：某些框架（如 Spring AOP）会自动包装异常，导致堆栈多出几层代理类。此时要结合 Thread.currentThread().getStackTrace() 或在关键入口加日志，确认真实调用链。
