本文讲解如何绕过异常对象的完整堆栈信息，直接获取并使用开发者设定的纯文本错误消息，适用于日志记录、前端提示或业务逻辑处理等无需抛出异常的场景。
本文讲解如何绕过异常对象的完整堆栈信息，直接获取并使用开发者设定的纯文本错误消息，适用于日志记录、前端提示或业务逻辑处理等无需抛出异常的场景。
在 Java 开发中，我们常通过 throw new Exception("自定义消息") 主动触发异常，但有时真正需要的并非异常本身，而是其中封装的语义化提示文本——例如用于日志写入、API 响应体构造或用户友好的错误提示。此时若仍沿用 throw + catch 流程，不仅引入不必要的异常开销（如堆栈快照生成），还容易混淆控制流语义。
✅ 正确做法是：避免无意义地创建和抛出异常，直接使用原始字符串。
例如：
// ❌ 不推荐：为打印消息而构造异常（低效且语义错误）
if (someCondition) {
throw new Exception("参数校验失败：用户名不能为空");
}
// ✅ 推荐：直接使用字符串，清晰、高效、可控
if (someCondition) {
String errorMessage = "参数校验失败：用户名不能为空";
// 后续可自由处理：写入日志、返回给前端、存入上下文等
log.error(errorMessage); // 如使用 SLF4J
response.setMessage(errorMessage); // 如构建 JSON 响应
}同理，在捕获异常后需替换为业务消息时：
try {
int result = 10 / divisor;
} catch (ArithmeticException e) {
// ❌ 避免：重新抛出新异常仅为了换消息（除非上层必须处理该异常类型）
// throw new RuntimeException("计算异常：除数不能为零");
// ✅ 推荐：提取意图，直接使用目标消息
String businessMessage = "计算异常：除数不能为零";
auditService.recordFailure(businessMessage);
notifyUser(businessMessage);
}⚠️ 注意事项：
- e.getMessage() 可从已捕获异常中提取原始消息，但不建议依赖它作为唯一消息源——因底层异常可能未设置消息，或消息格式不可控（如 NullPointerException 默认无 message）；
- 若必须保留异常链（如需调试溯源），可用 new RuntimeException("业务消息", e) 包装，但此时 getMessage() 仍只返回“业务消息”，符合“仅打印自定义消息”的需求；
- 所有消息应统一管理（如资源文件或常量类），便于国际化与维护。
总结：异常是控制流机制，不是消息容器。当目标仅为传递语义化文本时，请直接操作字符串——更轻量、更明确、更易测试与演进。
