抛出异常怎么处理：从捕获到恢复的实用指南

异常不是程序的终点

写代码时，谁还没遇到过程序突然崩掉的情况？点个按钮，页面直接白屏；调个接口，后台直接500。这些往往都是“抛出异常”惹的祸。很多人第一反应是赶紧加 try-catch，但真正的问题是：抛出异常怎么处理，才能让程序既不崩溃，又能给用户一个交代？

理解异常的本质

异常不是错误，而是程序在告诉你：“我现在遇到了无法继续下去的情况”。比如读文件时发现文件不存在，网络请求超时，数据库连接失败。这些都不是语法错，但程序不能像没事人一样继续跑下去。

Java 里常见的 NullPointerException，Python 中的 KeyError，JavaScript 的 TypeError，都是典型的运行时异常。它们一旦抛出，如果不处理，就会顺着调用栈往上冒，直到整个线程或进程挂掉。

捕获异常的基本姿势

最直接的处理方式就是捕获它。用 try-catch 包住可能出问题的代码块：

try {
    int result = 10 / 0;
} catch (ArithmeticException e) {
    System.out.println("别除零啊兄弟");
}

这样程序就不会因为一次除零操作直接退出。但注意，不能为了“不报错”就 catch 所有异常，然后啥也不做。这种“吞异常”的写法比不处理还危险，因为它让问题消失得无影无踪。

区分可恢复和不可恢复异常

有些异常是可以恢复的。比如网络请求失败，可以重试几次；文件找不到，可以提示用户重新选择路径。这种时候，捕获异常后应该给出补救措施。

int attempts = 0;
while (attempts < 3) {
    try {
        downloadFile(url);
        break; // 成功就跳出
    } catch (IOException e) {
        attempts++;
        Thread.sleep(1000);
    }
}

而像内存溢出（OutOfMemoryError）这种系统级问题，通常没法靠代码逻辑恢复。这时候更合理的做法是记录日志，尽快退出，避免数据损坏。

合理使用 finally 和 using

有些资源必须释放，不管有没有异常。比如打开了文件流、数据库连接、网络套接字。这时候 finally 块就派上用场了：

FileInputStream fis = null;
try {
    fis = new FileInputStream("data.txt");
    // 读取操作
} catch (IOException e) {
    e.printStackTrace();
} finally {
    if (fis != null) {
        try {
            fis.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

现代语言提供了更简洁的方式。Java 有 try-with-resources，C# 有 using，Python 有 with。它们能自动管理资源生命周期，减少样板代码。

不要忽略异常信息

catch 到异常后，至少要打一条日志，带上堆栈信息。否则出了问题根本没法查。打印日志时别只写“出错了”，要把异常对象本身传进去，让它输出完整的 trace。

在生产环境中，建议把关键异常上报到监控系统，比如 Sentry、ELK 或 Prometheus。这样即使用户没反馈，你也能第一时间知道哪里炸了。

自定义异常提升可读性

当你的业务逻辑中存在特定的错误场景，比如“用户余额不足”、“订单已取消”，可以直接定义自己的异常类型：

public class InsufficientBalanceException extends Exception {
    public InsufficientBalanceException(String message) {
        super(message);
    }
}

这样调用方可以根据具体的异常类型做出不同反应，而不是靠字符串判断错误原因。

向上抛还是自己扛？

有时候当前方法并不知道该怎么处理异常，比如底层 DAO 抛了个 SQL 异常，业务层可能更清楚该怎么做。这时候可以选择继续向上抛，让上层决定。

但要注意，不能一路往上抛到 main 函数还不处理。就像快递包裹不能一直转寄，最后没人签收就会退回。

合理的做法是，在合适的层级做统一处理。Web 项目通常会在控制器层加全局异常处理器，返回友好的错误页面或 JSON 响应，而不是让用户看到一屏红色堆栈。