Java try-catch用法与实用技巧

Java异常处理的核心在于精准区分编译期异常与运行时异常：前者（如IOException、SQLException）必须用try-catch或throws显式处理，后者（如NullPointerException、IllegalArgumentException）应通过前置校验和逻辑修复来避免，而非依赖捕获掩盖问题；推荐优先使用try-with-resources自动管理资源，确保安全关闭；多异常捕获需注意继承顺序与类型兼容性，重抛异常时务必保留原始栈轨迹并合理封装上下文；真正健壮的异常处理不是堆砌catch块，而是让错误可定位、可恢复、不扩散——少写复杂业务逻辑于catch中，不滥用Exception兜底，更不将异常当作控制流，才能写出清晰、高效、易维护的Java代码。

什么时候必须用 try-catch，什么时候可以不用

Java 中 try-catch 不是万能兜底工具，也不是所有异常都该捕获。编译期异常（Exception 及其子类，但不包括 RuntimeException）必须处理——要么 try-catch，要么在方法签名加 throws。运行时异常（如 NullPointerException、ArrayIndexOutOfBoundsException）可不捕获，因为它们通常反映逻辑错误，应靠修复代码而非掩盖异常来解决。

常见误用：对 Integer.parseInt(str) 硬套 try-catch 而不先校验 str 是否为空或纯数字。这会让异常成为控制流，性能差且难调试。

• 必须捕获：文件读写（IOException）、网络请求（SQLException、UnknownHostException）等外部依赖失败场景
• 建议不捕获：NullPointerException、IllegalArgumentException —— 应提前用 Objects.requireNonNull() 或空检查拦截
• 谨慎捕获：Exception 或 Throwable —— 容易吞掉 OutOfMemoryError 这类致命错误

多个 catch 块的顺序与合并写法

多个 catch 块必须按「子类在前、父类在后」排列，否则编译报错：error: exception XXX has already been caught。Java 7 起支持多异常捕获语法，用 | 分隔，但要注意：被合并的异常类型不能有继承关系，且共用一个处理逻辑时才适用。

try {
    doSomething();
} catch (IOException | SQLException ex) {
    log.error("I/O or DB failed", ex);
} catch (IllegalArgumentException ex) {
    // 单独处理参数问题
    throw new BusinessException("Invalid input", ex);
}

• 错误顺序示例：catch (Exception e) 写在 catch (IOException e) 前 → 编译失败
• 合并后异常对象类型是 Capture#1，无法调用子类特有方法（如 SQLException.getSQLState()），需拆开处理
• catch (Exception e) 后面不能再跟其他 catch —— 它已覆盖全部异常

try-with-resources 自动关闭资源的正确姿势

凡实现 AutoCloseable 接口的对象（如 FileInputStream、Connection、Scanner）都应优先用 try-with-resources，它比手动 finally 关闭更可靠：即使 try 块中抛出异常，资源仍会被关闭，且关闭异常不会掩盖主异常（会作为 suppressed exception 附加）。

try (BufferedReader reader = new BufferedReader(new FileReader("data.txt"));
     PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users")) {
    String line = reader.readLine();
    stmt.execute();
} catch (IOException | SQLException e) {
    log.warn("Operation failed", e);
}

• 资源声明必须在 try 括号内，且只能是有效 final 或实际 final 变量
• 不要在 try 块里重新赋值资源变量（如 reader = null），会导致关闭空指针
• 若需访问 suppressed exception，用 e.getSuppressed() 获取数组，但生产环境一般不依赖它做业务判断

catch 中该不该重新抛出异常，怎么抛

捕获异常后直接 throw e; 是常见反模式——会丢失原始栈轨迹。需要增强上下文或转换异常类型时，应显式构造新异常并传入原异常作 cause：

try {
    parseJson(input);
} catch (JsonParseException e) {
    throw new BadRequestException("Failed to parse JSON in request body", e);
}

• 避免裸 throw e; 或 throw new RuntimeException(e); —— 前者未加信息，后者丢失原始类型
• 日志记录后继续抛出，用 log.debug("Ignored error", e); throw e;，但仅限明确要上抛的场景
• 若 catch 后决定“吃掉”异常（极少数情况，如清理临时文件失败可忽略），至少加注释说明理由，且不要静默吞掉 InterruptedException

异常处理不是越细越好，关键是让错误可定位、可恢复、不扩散。最常被忽略的一点：catch 块里别写复杂业务逻辑——它本该专注错误响应，而不是补救、重试或降级；那些该交给上层策略或专门的容错组件去做。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~