Java异常处理：别过度捕获异常

Java异常处理的核心在于精准与责任：只捕获明确知晓如何应对的具体异常类型，坚决避免捕获Throwable或泛型Exception以防掩盖JVM致命错误或破坏受检异常的设计契约；受检异常必须显式恢复、转换或向上声明，绝不能静默吞掉；finally块中须防止覆盖原始异常，优先采用try-with-resources或正确抑制次要异常；自定义异常应依场景理性选择继承RuntimeException（针对不可预见的程序缺陷）还是Exception（针对可恢复的外部故障），并确保构造函数完整传递异常链。这不仅是编码规范，更是保障系统可观测性、可维护性与业务健壮性的关键实践。

不要在 catch 块里捕获 Throwable 或 Exception

捕获 Throwable 会吞掉 OutOfMemoryError、StackOverflowError 等 JVM 严重错误，导致程序在不可恢复状态下继续运行；捕获泛型的 Exception 则大概率掩盖本该向上抛出的受检异常意图，或误吞 InterruptedException 这类需特殊处理的异常。

实操建议：

• 只捕获你明确知道如何处理的具体异常类型，例如 IOException、SQLException
• 若需兜底，用 catch (RuntimeException e) + 单独 catch (Error e)（且通常应记录后重新抛出）
• 避免写

  try { ... } catch (Exception e) { log.error("unexpected", e); }

  —— 这不是容错，是埋雷

受检异常（checked exception）不该被“静默吞掉”

Java 要求显式处理受检异常，但很多人用空 catch 块、仅打印日志却不重试/补偿/通知，等于把业务逻辑的失败信号直接丢弃。调用方完全感知不到操作其实失败了。

常见错误现象：

• catch (IOException e) { /* empty */ } —— 文件写失败，但后续代码仍假设文件已落盘
• catch (SQLException e) { logger.warn("DB failed", e); return null; } —— 上层拿到 null 却未做判空，触发 NullPointerException

正确做法：

• 要么恢复：重试、降级、返回默认值（需明确语义，如缓存读取失败时返回旧值）
• 要么转换：包装成更上层能理解的业务异常，如 throw new OrderCreationFailedException("payment timeout", e);
• 要么声明抛出：如果当前方法无法处理，就加 throws IOException，让调用方决策

别在 finally 里覆盖原始异常

当 try 块抛出异常，而 finally 块又抛出另一个异常时，原始异常会被彻底丢失 —— JVM 只保留 finally 中抛出的那个，调试时根本看不到真正出问题的地方。

示例问题代码：

try {
    return readFile(path);
} finally {
    closeStream(); // 若这里抛出 IOException，readFile 的异常就消失了
}

解决方式：

• 用 try-with-resources 替代手动 close()，它会自动抑制次要异常
• 若必须手动关闭，应在 finally 中用 if (resource != null) resource.close(); 并捕获其异常，不抛出
• JDK 7+ 可用 Throwable.addSuppressed() 显式保留原始异常，但日常开发中优先选前两种

自定义异常别滥用 extends Exception

继承 Exception 意味着强制调用方处理，但如果这个异常本质上是程序 bug（比如传入非法参数），应该继承 RuntimeException；反之，如果异常代表外部可恢复故障（如网络超时），才考虑设计为受检异常。

判断依据：

• 调用方能否预见该异常发生？能 → 受检；不能（纯逻辑错）→ 非受检
• 调用方是否有合理手段恢复？有（如重试、切换备用源）→ 受检；无 → 非受检
• 是否需要强制 API 使用者关注失败路径？是 → 受检；否则非受检更轻量

一个容易被忽略的细节：自定义异常构造函数务必调用 super(message, cause)，否则链路追踪时会丢失根因堆栈。

到这里，我们也就讲完了《Java异常处理：别过度捕获异常》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！