本文详解在 try-catch 中抛出自定义异常的规范做法，重点剖析直接捕获通用 exception、丢弃原始堆栈、忽略因果链等典型反模式，并提供可落地的重构方案与最佳实践。
本文详解在 try-catch 中抛出自定义异常的规范做法，重点剖析直接捕获通用 exception、丢弃原始堆栈、忽略因果链等典型反模式，并提供可落地的重构方案与最佳实践。
在 Java 异常处理中，看似简单的代码片段往往暗藏设计隐患。例如以下写法：
public void method() {
try {
throw new MyException("Error occurred");
} catch (Exception e) {
throw new MyException("Something went wrong");
}
}表面看是“捕获后重抛”，实则存在三重严重问题：逻辑冗余、因果链断裂、类型滥用。它并非异常转换，而是用 try-catch 故意绕过控制流——第一行抛出的异常必然被同一 catch 捕获，原始消息 "Error occurred" 永远不会暴露，堆栈跟踪也指向第二处 throw，彻底掩盖真实错误源头。
✅ 正确做法一：精准捕获 + 保留因果链
应明确区分“本意就是抛出该异常”与“因其他异常而兜底处理”。若需包装异常，必须传递原始 Throwable 作为 cause：
// ✅ 正确：保留原始异常上下文
try {
riskyOperation();
} catch (MyException e) {
throw e; // 直接重抛，不丢失堆栈
} catch (Exception e) {
throw new MyException("Operation failed unexpectedly", e); // 关键：传入 e 作为 cause
}为此，你的自定义异常类必须支持带 cause 的构造器：
public class MyException extends Exception {
public MyException(String message) {
super(message);
}
// 必须提供此构造器，否则无法建立因果链
public MyException(String message, Throwable cause) {
super(message, cause);
}
}⚠️ 若无法修改旧版异常类（如第三方库），可用 initCause() 补救：
MyException wrapped = new MyException("Fallback error"); wrapped.initCause(originalException); // 手动注入因果关系 throw wrapped;
✅ 正确做法二：消息设计遵循“类型语义 + 补充信息”原则
异常消息不是自由文本，而是结构化诊断数据。类型名定义问题范畴，消息仅补充唯一性上下文：
// ✅ 推荐：类型精准 + 消息精简（仅文件路径）
throw new NoSuchFileException("/data/config.json");
// ❌ 反模式：消息重复类型语义
throw new NoSuchFileException("File not found: /data/config.json"); // "not found" 冗余
throw new RuntimeException("Something went wrong"); // 类型模糊，消息无信息量
throw new IOException("Error! Failed to read!"); // 标点干扰，且未说明具体资源理想的消息应满足：无标点结尾、不含类型同义词、仅含业务关键参数（如 ID、URL、配置项名）。
✅ 正确做法三：慎用 catch (Exception e) —— 仅限 Launch Point Runner
通用异常捕获（catch (Exception e)）仅在“启动点处理器”（Launch Point Runner）中合法，例如：
- public static void main(String[] args) throws Exception
- Web 框架中的 Controller 方法（由 Spring/Dropwizard 等统一拦截）
- 消息队列消费者入口方法
这些位置的职责是：统一记录日志、添加请求上下文（IP/TraceID）、返回用户友好错误页、触发告警。此时捕获 Exception 是合理的，因为所有未处理异常都应交由该层兜底。
而在业务逻辑层，catch (Exception e) 是危险信号。它会吞噬 InterruptedException、OutOfMemoryError 等本应立即终止的严重异常，或掩盖本可针对性恢复的特定异常（如 SQLException 可重试，IllegalArgumentException 应修正输入）。应改为：
// ✅ 按需捕获具体异常
try {
saveToDatabase(data);
} catch (SQLTimeoutException e) {
retryWithBackoff(); // 可恢复场景
} catch (SQLIntegrityConstraintViolationException e) {
throw new BusinessException("Duplicate key: " + data.getId(), e);
} catch (SQLException e) {
throw new DataAccessException("Failed to persist data", e); // 包装为领域异常
}总结：三条黄金准则
- 绝不为跳转而用 try-catch：若无真正异常处理逻辑（如重试、降级、日志增强），就不要人为制造 try-catch；直接抛出更清晰。
- 包装必传 cause：任何新抛异常若源于另一异常，必须通过构造器或 initCause() 保留原始 Throwable，确保调试时可追溯根因。
- 捕获要具体，兜底要顶层：业务层只捕获能理解并响应的异常类型；全局兜底逻辑交给框架或主入口，避免分散处理。
遵循这些原则，你的异常处理将从“错误掩盖器”转变为“故障定位仪”——既提升系统可观测性，也大幅降低线上问题排查成本。
