运行时异常要捕获吗

这是一个非常经典且重要的 Java 问题。简短的回答是：绝大多数情况下不需要，也不应该捕获运行时异常（RuntimeException），但在特定的边界场景下需要。

下面详细解释为什么，以及什么时候该破例。

1. 什么是运行时异常？

运行时异常（继承自 java.lang.RuntimeException）通常代表程序逻辑错误（Bug），而不是外部环境问题。

• 常见例子：NullPointerException (空指针)、ArrayIndexOutOfBoundsException (数组越界)、IllegalArgumentException (参数非法)。

2. 为什么通常“不要”捕获？

Java 设计运行时异常的初衷就是非受检异常（Unchecked Exception），目的是让程序员必须修复代码，而不是用 try-catch 掩盖问题。

如果你捕获了它们，通常会导致以下后果：

1. 掩盖 Bug：程序明明有逻辑错误（比如对象没初始化），你捕获了异常并吞掉（或者只打个日志），程序继续运行。这会导致后续产生更诡异、更难排查的数据错误。
2. 违背设计初衷：NullPointerException 的出现意味着你的代码写得不严谨，应该去修代码（加判空、判空初始化），而不是捕获它。
3. 代码结构臃肿：如果捕获运行时异常，代码中会充斥着大量 try-catch，导致代码可读性变差。

最佳实践：

不要捕获运行时异常，让它们抛出来，直到最顶层的全局异常处理器（或者 JVM）处理它们。

3. 什么时候“需要”捕获？

虽然不建议在业务逻辑中间捕获，但在以下边界场景中，捕获是必要的：

场景一：防止线程/进程崩溃（最顶层兜底）

在线程入口、任务执行器或Web 请求的入口，你需要捕获所有异常（包括运行时异常），防止因为一个请求的 Bug 导致整个服务挂掉。

• Web 后端：Spring MVC 的 @ControllerAdvice 就是干这个的。
• 线程池：ExecutorService 的 afterExecute 或者 ThreadFactory 的 UncaughtExceptionHandler。

// 示例：线程池中的任务，如果不捕获，异常可能导致线程终止
try {
    processTask(data);
} catch (RuntimeException e) {
    log.error("Task failed, but thread will survive", e);
    // 记录日志、报警、放入死信队列，但不要抛出去让线程死掉
}

场景二：将异常转换为另一种形式

当你调用第三方库或底层代码时，如果它抛出了运行时异常，但你希望向上层抛出一个业务异常（Checked Exception 或自定义异常），这时需要捕获并转换。

public void saveUser(User user) {
    try {
        dao.save(user);
    } catch (NullPointerException e) {
        // 捕获底层的空指针，转换为业务含义明确的异常
        throw new InvalidDataException("User data cannot be null", e);
    }
}

场景三：资源清理（仅限 finally）

如果你在 try 块里打开了资源（如文件流、数据库连接），即使发生运行时异常，你也需要确保资源被关闭。但这通常配合 finally 或者 try-with-resources 使用，而不是为了“处理”异常。

InputStream in = null;
try {
    in = new FileInputStream("file.txt");
    // ... 可能抛出 RuntimeException
} finally {
    if (in != null) in.close(); // 确保关闭，不管有没有异常
}

场景四：无法修复但必须继续

极少数情况下，你知道某个操作可能会失败（比如解析用户输入的字符串转数字），且失败是预期内的，你可以捕获 NumberFormatException。但这通常更推荐用 防御性编程（如正则校验）来避免异常。

4. 总结与决策树

一句话总结：

不要试图在代码中间“治愈”运行时异常，要在代码边界“防御”它们。 让 Bug 暴露出来，而不是藏起来。