Throws和TryCatch选哪个

这是一个非常经典的问题。简单来说：“能处理的错误用 Try-Catch，不能处理（或需要向上传递）的错误用 Throws。”

但在实际开发中，选择哪一个取决于错误的性质以及你在代码中的层级。

以下是详细的决策指南和对比分析：

1. 核心区别

2. 决策流程图（怎么选？）

你可以问自己两个问题：

1. 在这个位置，我有能力修复这个问题吗？
   • 有 -> 用 try-catch。
   • 没有 -> 用 throws。
2. 这个错误是“业务预期内”的吗？
   • 是（例如：用户输入了错误的密码、文件不存在、余额不足） -> 用 try-catch 提示用户或做逻辑分支。
   • 否（例如：数据库连接断了、空指针、代码逻辑写错了） -> 通常 throws 到顶层统一处理，或者捕获后包装成自定义异常再抛出。

3. 场景举例

场景一：底层工具类（使用 throws）

你写了一个读取文件的方法，这个方法本身不知道如果文件不存在该怎么办（是创建新文件？还是报错？）。所以你不应该在这里决定，而是把问题抛出去。

// 底层方法：只负责读取，不负责处理错误
public String readFile(String path) throws IOException {
    // 如果文件不存在，这里会抛出 IOException
    FileInputStream fis = new FileInputStream(path); 
    // ... 读取逻辑
    return "content";
}

场景二：业务层/UI层（使用 try-catch）

在调用上述方法的地方，你作为业务开发者，知道如果文件不存在，应该给用户一个提示。

// 上层调用：负责处理错误
public void displayFileContent() {
    try {
        String content = readFile("config.txt");
        System.out.println(content);
    } catch (IOException e) {
        // 在这里处理：告诉用户文件找不到
        System.out.println("错误：配置文件丢失，请检查路径！");
        // 或者记录日志
        log.error("File not found", e);
    }
}

场景三：转换异常类型（组合使用）

有时候底层抛出的异常太底层了（比如 SQLException），上层业务看不懂。这时候可以捕获它，然后抛出一个业务异常。

public void processOrder() throws OrderProcessingException {
    try {
        // 数据库操作
        dao.saveOrder();
    } catch (SQLException e) {
        // 捕获底层异常，包装成业务异常再抛出
        throw new OrderProcessingException("保存订单失败，数据库异常", e);
    }
}

4. 最佳实践建议

1. 不要吞掉异常： 最差的做法是 catch 了异常却什么都不做（空块）。这会让程序在出错时毫无反应，极难调试。

   // 错误示范
   try { ... } catch (Exception e) {} 
   

2. 尽量精确捕获： 不要一上来就 catch (Exception e)。尽量捕获具体的异常（如 IOException, NullPointerException），这样处理逻辑更精准。

3. 在main方法或全局入口处兜底： 即使你到处 throws，最终在 main 方法或者 Web 框架的全局异常处理器（如 Spring 的 @ControllerAdvice）中，一定要有一个最终的 try-catch 来捕获未被处理的异常，防止程序直接崩溃。

4. 清理资源用 finally 或 try-with-resources： 如果是打开文件、数据库连接，无论是否出错都要关闭，放在 finally 块里，或者用 Java 7+ 的 try (Resource r = ...) { ... } 语法。

总结

• throws 是甩锅，把问题丢给上级。
• try-catch 是解决问题，或者把问题包装成上级能听懂的话再丢出去。

一句话口诀： “底层抛，上层抓；能处理就抓，不能处理就抛。”