Java受检异常显著抬高重构成本，体现为编译强制传播、调用链耦合和接口契约锁定三方面，导致异常类型变更需全链扫描、同步更新throws声明及catch块，并限制实现类异常声明自由度。
Java中受检异常的throws签名会显著抬高重构成本，主要体现在编译强制性、调用链耦合和接口契约锁定三方面。它不是单纯的技术声明，而是一条贯穿整个调用链的“编译期契约”，一旦修改，影响范围远超方法本身。
编译器强制传播导致重构必须全链扫描
受检异常通过throws声明后，调用方若不处理（try-catch）就必须继续声明。这意味着一次异常类型变更（如将IOException细化为FileNotFoundException），可能触发从底层工具方法→服务层→API入口的整条调用链重新编译失败。重构时不能只改一个方法，必须顺藤摸瓜找出所有上层声明或捕获该异常的位置，否则编译直接中断。
- 新增一个受检异常类型，所有中间层方法签名都要同步追加
throws，哪怕它们只是透传 - 删除某个
throws声明，需确认该异常确实不再被抛出——包括所有被调用的子方法、第三方库调用路径 - 替换异常类型（如用自定义
ConfigLoadException替代IOException），所有上层catch块和throws列表都要逐一手动更新
接口与实现强绑定加剧重构阻力
接口方法一旦声明throws SQLException，所有实现类都必须遵守：不能删，不能换成无关异常，只能缩小（如不抛、或只抛SQLTimeoutException）。这使得重构变得脆弱：
- 想把数据库访问逻辑抽成内存缓存实现？原接口要求
throws SQLException，但缓存根本不抛这个异常——你得要么保留无意义的声明，要么改接口，进而波及所有调用者 - 升级JDBC驱动后，某操作不再抛
SQLFeatureNotSupportedException，但接口仍声明它，实现类无法擅自移除，否则编译报错 - 微服务拆分时，若原单体接口含多个受检异常，新服务边界难以干净切割，常被迫保留冗余声明以维持二进制兼容
异常粒度粗大会放大重构风险
为图省事声明throws Exception看似简化，实则埋下重构地雷：
立即学习“Java免费学习笔记（深入）”；
- 调用方只能统一
catch (Exception e)，无法区分是网络超时还是配置错误，重构时无法针对性优化恢复策略 - 后续想拆分异常类型（如分离
NetworkException和ValidationException），需同时修改所有调用点的catch逻辑，极易遗漏 - 静态分析工具难以识别真实异常流，重构辅助（如自动提取方法、内联）可能因异常语义模糊而失效或出错
降低重构成本的务实做法
不是放弃throws，而是控制其影响半径：
- 工具层方法谨慎使用受检异常——优先封装为运行时异常（如
IllegalArgumentException）或自定义非受检业务异常，避免污染上层 - 接口设计阶段明确异常分类，用具体子类（
FileNotFoundConfigException）代替宽泛父类（IOException），让重构变更更局部 - 重构前用IDE的“Find Usages”功能导出所有
throws和catch位置，建立影响清单，避免漏改 - 对遗留系统，可阶段性引入
@SuppressWarnings("checkstyle:ThrowsDeclaration")等标记标注待重构点，而非强行一步到位
