Java异常信息编写规范说明

异常信息须含可定位上下文：明确类/方法、操作对象及失败原因；禁用泛化消息；自定义异常需重写getMessage()且不抛新异常；业务校验不用异常；包装异常须保留真实cause链。

异常信息必须包含“可定位的上下文”

Java里抛出的异常如果只写 "Error occurred" 这类泛化消息，等于没写。调用方根本无法判断是参数错、资源不可用，还是逻辑分支没覆盖。真正有用的异常信息要能回答三个问题：在哪发生的（类/方法）、对什么操作失败了（关键输入或状态）、为什么失败（直接原因）。

实操建议：

• 用模板句式："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。

实操建议：

• 所有自定义异常必须显式覆写 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，这是典型误用。异常是给开发者看的故障信号，不是给终端用户读的友好提示。

实操建议：

• 参数校验失败、业务规则拒绝等预期场景，应走正常返回路径（如 ResponseEntity.badRequest().body(...)），附带结构化错误码和用户语言提示
• 异常仅用于非预期路径：文件突然被删、远程服务无响应、JSON 解析器内部状态损坏等“程序不该走到这里”的情况
• 若框架强制要求异常转响应（如 Spring 的 @ExceptionHandler），也要在 handler 里剥离技术细节，重新组装面向用户的提示，而不是直接返回 e.getMessage()

getCause() 链必须保持真实且不截断

常见错误是捕获异常后“美化”再抛出：throw new ServiceException("Operation failed", e.getCause())，结果把中间一层 SQLException 给丢了，只剩最外层包装。调试时看到的是 ServiceException 套着 NullPointerException，但真实根因是数据库连接池耗尽。

实操建议：

• 包装异常时，始终用原始异常作 cause，不要取 e.getCause() 再传——除非你明确知道那层是冗余噪音（极少见）
• 避免多层无意义包装：不要从 IOException → DaoException → ServiceException → ApiException，保留两层以内更利于归因
• 日志打印时务必用 logger.error("xxx", e) 而不是 logger.error("xxx " + e.getMessage())，否则堆栈链丢失