java受检异常处理必须形成贯穿调用链的责任链，所有直接或间接调用可能抛出受检异常方法的代码均需参与；每层必须显式选择throws声明或try-catch处理，不可中断、忽略或空捕获，终点为应用边界如controller层统一转换为用户友好响应。
Java中受检异常的处理不是单点动作，而是一条必须贯通的责任链：从异常发生处开始，每一层调用者都必须明确选择“捕获”或“声明抛出”，否则编译失败。这条链不能中断，也不能隐式忽略。
谁必须参与这条链？
所有在调用链上直接或间接使用了可能抛出受检异常方法的代码，都自动进入责任链。比如你调用了FileInputStream构造器（抛FileNotFoundException），哪怕只隔了一层包装方法，该方法也必须声明throws IOException，或者自己用try-catch兜住。
- 底层IO操作 → 抛出
IOException - 业务服务方法调用该IO操作 → 必须声明
throws IOException，或捕获并转换为自定义异常 - Controller层接收请求并调用该服务 → 同样要处理，不能只写
try却不写catch或throws
责任链的两种合法走向
每层只能选其一，不可两者都不做，也不可仅记录日志却不处理语义：
-
向上声明（throws）：把异常原样或包装后继续抛给上层，适用于当前层无能力恢复、且上层更清楚如何应对的场景（如DAO层抛
SQLException，Service层决定重试还是转成业务异常） -
就地捕获（try-catch）：在当前层完成恢复动作，比如重试一次、提供默认值、降级响应；但注意——不能只
catch不handle，空catch块是责任链断裂的典型表现
常见断裂点与修复方式
责任链最容易在以下位置无声断裂，导致编译错误或运行时隐患：
- lambda表达式中调用受检异常方法 → 编译报错，需用工具类封装（如
IOUtils.silentClose()）或自定义函数式接口 - 重写父类/接口方法时忽略
throws声明 → 子类方法不能抛出比父类更宽泛的受检异常，需提前规划异常兼容性 - 用
Runnable或Callable提交任务时 → 原生接口不支持throws，必须在内部try-catch并转为RuntimeException包装再抛
责任链终点在哪里？
链的终点通常是应用边界：比如Web层的Controller、定时任务入口、消息监听器。这里不再向上抛出，而是统一转化为用户友好的提示、HTTP状态码或日志告警。例如：
- Spring MVC中用
@ExceptionHandler集中拦截IOException，返回500+错误信息 - 命令行程序在main方法里
try-catch并打印提示后退出 - 绝不让受检异常穿透到UI线程或外部API消费者，那是设计失职
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
