异常信息须含可定位上下文：明确类/方法、操作对象及失败原因；禁用泛化消息；自定义异常需重写getMessage()且不抛新异常；业务校验不用异常；包装异常须保留真实cause链。
异常信息必须包含“可定位的上下文”
Java里抛出的异常如果只写 "Error occurred" 这类泛化消息，等于没写。调用方根本无法判断是参数错、资源不可用，还是逻辑分支没覆盖。真正有用的异常信息要能回答三个问题：在哪发生的（类/方法）、对什么操作失败了（关键输入或状态）、为什么失败（直接原因）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用模板句式：
"Failed to [verb] [resource/object] due to [specific cause]"，例如"Failed to parse JSON string 'user_data' due to malformed UTF-8 byte sequence" - 避免在消息里拼接敏感数据（如密码、token），可用占位符代替：
"Failed to connect to database at jdbc:mysql://***:3306/mydb" - 不要依赖日志级别来“补全”信息——
catch块里log.error("xxx", e)的日志内容，和e.getMessage()应该各自完整，不能互相依赖
自定义异常类必须重写 getMessage() 且不抛出新异常
很多团队建了 UserNotFoundException 却没重写 getMessage()，导致实际抛出时只有类名，或者重写时又调用了可能抛异常的方法（比如去查数据库拼消息），这会让原始错误被掩盖甚至引发 StackOverflowError。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 所有自定义异常必须显式覆写
getMessage()，且只基于构造时传入的字段拼接，不调用外部方法 - 推荐构造函数签名统一为：
public MyException(String message, Throwable cause)和public MyException(String template, Object... args)（用String.format安全填充） - 禁止在
getMessage()中做格式化失败兜底（比如try-catch吞掉IllegalFormatException），那说明模板本身就有问题，该在测试阶段暴露
不要用异常信息替代业务校验提示
用户提交手机号为空，后端抛 IllegalArgumentException("phone is null") 并返回 HTTP 500，这是典型误用。异常是给开发者看的故障信号，不是给终端用户读的友好提示。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 参数校验失败、业务规则拒绝等预期场景，应走正常返回路径（如
ResponseEntity.badRequest().body(...)），附带结构化错误码和用户语言提示 - 异常仅用于非预期路径：文件突然被删、远程服务无响应、JSON 解析器内部状态损坏等“程序不该走到这里”的情况
- 若框架强制要求异常转响应（如 Spring 的
@ExceptionHandler），也要在 handler 里剥离技术细节，重新组装面向用户的提示，而不是直接返回e.getMessage()
getCause() 链必须保持真实且不截断
常见错误是捕获异常后“美化”再抛出：throw new ServiceException("Operation failed", e.getCause())，结果把中间一层 SQLException 给丢了，只剩最外层包装。调试时看到的是 ServiceException 套着 NullPointerException，但真实根因是数据库连接池耗尽。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 包装异常时，始终用原始异常作
cause，不要取e.getCause()再传——除非你明确知道那层是冗余噪音（极少见） - 避免多层无意义包装：不要从
IOException→DaoException→ServiceException→ApiException，保留两层以内更利于归因 - 日志打印时务必用
logger.error("xxx", e)而不是logger.error("xxx " + e.getMessage())，否则堆栈链丢失
