Java中try-catch用于捕获可预知、可恢复、需干预的异常，应分层捕获受检异常，避免裸捕RuntimeException；需用try-with-resources、保留异常链、明确throws声明。
Java 中的 try-catch 是处理运行时异常的核心机制，它不为兜底所有错误而设，而是用于捕获并响应那些**可预知、可恢复、需干预**的异常场景。关键在于理解“什么能捕、怎么捕、捕了之后做什么”，而不是无差别包裹代码。
try-catch 的基本结构与执行逻辑
try 块中只放真正可能抛出异常的语句；一旦发生异常，JVM 立即中断 try 内剩余代码，跳转至匹配的 catch 块；若没有匹配的 catch，则异常向上抛给调用者。finally（可选）无论是否异常、是否 return，都会执行，适合做资源释放。
- try 不能单独存在，必须跟 catch 或 finally 至少其一
- 多个 catch 时，子类异常（如 FileNotFoundException）必须写在父类（如 IOException）之前，否则编译报错
- catch 中的异常变量（如 e）可调用 getMessage()、printStackTrace()、getCause() 获取上下文
哪些异常值得捕获？哪些不该捕
Java 区分受检异常（checked）和非受检异常（unchecked）。前者继承自 Exception 但不包括 RuntimeException 及其子类，编译器强制你处理——比如 IOException、SQLException；后者如 NullPointerException、ArrayIndexOutOfBoundsException，属于编程疏漏，应修复而非捕获。
- ✅ 应捕获：文件不存在、网络超时、数据库连接失败等外部依赖导致的受检异常
- ❌ 避免捕获：RuntimeException 类型的裸 catch（如 catch(Exception e)），会掩盖空指针、数组越界等本该修复的 bug
- ⚠️ 特殊情况：反射调用失败时，InvocationTargetException 的 getCause() 才是真实业务异常，需解包处理
正确写法示例：兼顾安全与可维护性
下面是一个读取配置文件并解析 JSON 的典型场景，展示了资源管理、异常细化、日志记录和异常链保留：
立即学习“Java免费学习笔记（深入）”；
public String loadConfig(String path) throws ConfigLoadException {
try (FileInputStream fis = new FileInputStream(path);
InputStreamReader reader = new InputStreamReader(fis, StandardCharsets.UTF_8)) {
String content = new String(Files.readAllBytes(Paths.get(path)), StandardCharsets.UTF_8);
return parseJson(content); // 可能抛出自定义 ConfigParseException
} catch (FileNotFoundException e) {
throw new ConfigLoadException("配置文件未找到: " + path, e);
} catch (IOException e) {
throw new ConfigLoadException("读取配置文件失败", e);
}
}
- 使用 try-with-resources 自动关闭流，无需手动 finally
- 按异常类型分层捕获，不合并处理不同原因的错误
- 重新抛出自定义异常时传入原始异常作为 cause，保留完整栈轨迹
- 方法签名明确声明 throws ConfigLoadException，体现契约责任
常见误区与规避方式
很多问题不是语法不会写，而是对异常本质理解偏差造成的。
- 空 catch 块（catch(Exception e) { }）：等于静默吞掉错误，调试时无迹可寻
- 在 finally 中 return 或抛异常：会覆盖 try/catch 中的返回值或异常，导致逻辑失控
- 把大量无关代码塞进 try：扩大异常影响范围，干扰问题定位
- 忽略受检异常的编译强制要求：直接删掉 throws 或 catch 后不处理，编译失败
