受检异常处理：何时不应使用try-catch

受检异常不应盲目用try-catch处理，而应根据场景选择抛出、校验或使用try-with-resources：一是编程错误需提前校验而非捕获；二是调用方更适于决策应声明throws；三是资源管理应交由try-with-resources；四是框架已统一拦截时避免重复处理。

受检异常（Checked Exception）是 Java 中必须显式处理的异常类型，比如 IOException、SQLException。但“必须处理”不等于“必须用 try-catch 包裹”。很多开发者一看到编译报错就本能地加 try-catch，结果反而掩盖语义、破坏流程、增加维护成本。真正该规避 try-catch 的场景，往往出现在逻辑本就不该出错、或错误应由上层统一消化的地方。

不该用 try-catch 的情况一：异常本质是编程错误

当受检异常暴露的是代码缺陷时，捕获它只是在掩盖问题，而不是解决问题。例如：

• 空文件路径传给 FileInputStream：这不是外部环境不稳定导致的 IO 异常，而是参数校验缺失。应提前检查 path != null && !path.trim().isEmpty()，而非等抛出 FileNotFoundException 再 catch。
• 硬编码 SQL 字符串拼接后执行：若因字段名写错触发 SQLException，说明 SQL 编写阶段缺乏校验或使用了过时方式。应改用预编译、ORM 或 SQL 模板工具，让错误在开发期暴露，而非运行期靠 try-catch 补救。

不该用 try-catch 的情况二：调用方更清楚如何应对

如果当前方法无法做任何有意义的恢复动作（比如重试、降级、返回默认值），强行捕获只会把异常“截胡”，剥夺上层根据业务上下文决策的机会。典型例子：

• DAO 层的 findUserById(Long id) 方法抛出 SQLException，Service 层不应直接 try-catch 并返回 null —— 这会让调用方误以为“用户不存在”，而实际可能是数据库连接池耗尽。正确做法是声明 throws SQLException，由 Controller 或网关层结合监控、熔断策略统一响应。
• 工具类中的 parseXml(String xml) 若抛出 ParserConfigurationException，说明 XML 解析器初始化失败。这种配置级错误通常意味着应用启动异常，应在初始化阶段 fail-fast，而不是在每次调用时 try-catch 吞掉。

不该用 try-catch 的情况三：资源管理已由更优机制覆盖

对于需要显式关闭的资源（如流、连接），用 try-catch 手动关闭既冗余又危险——容易遗漏 finally 或关闭失败引发二次异常。Java 7+ 提供的 try-with-resources 已自动承担此职责：

• ❌ 错误写法：try { InputStream is = new FileInputStream(...); ... } catch (IOException e) { log.error(...); } —— is 未关闭，且异常处理不完整。
• ✅ 正确替代：try (InputStream is = new FileInputStream(...)) { ... } —— 异常仍会向上抛，资源自动释放，无需额外 try-catch。

不该用 try-catch 的情况四：异常会被框架统一拦截

在 Spring Web 等现代框架中，Controller 层之上已有全局异常处理器（如 @ControllerAdvice + @ExceptionHandler）。此时在每个接口内部重复 try-catch，不仅多余，还会干扰事务控制、日志归因和统一响应格式：

• 例如，一个转账接口内手动 catch SQLException 并返回 Result.error("数据库忙")，就绕过了框架对事务回滚的判断逻辑，也割裂了错误码体系。
• 合理做法是让异常自然抛到 Controller 层，由全局处理器识别 SQLException 并映射为 503、记录告警、返回标准错误体。