Java+Cucumber框架：将受检异常转为运行时异常是否可行？

结论：这个方案完全可行，是测试框架中的常规优化手段 #

• 彻底消除冗余的throws声明：在基础/通用方法里捕获受检异常，转换为运行时异常抛出后，所有上层调用方法都无需再声明throws，直接解决了代码“冗余杂乱”的问题，可读性大幅提升。
• 匹配Cucumber的失败处理逻辑：你提到的这类受检异常（文件读取失败、JSON解析错误）属于测试执行的致命问题，一旦发生当前测试必然无法继续。转换为运行时异常后，Cucumber会自动捕获异常、标记当前场景失败，然后继续执行下一个场景，最终效果和原来直接抛出受检异常完全一致。
• 自定义运行时异常更利于排查：可以不用Java自带的RuntimeException，而是自定义一个继承它的子类（比如TestResourceLoadException），在抛出时传入原始异常作为cause，这样日志里能更清晰地定位问题类型，方便后续排查。

关键注意事项 #

• 绝对不能吞掉原始异常：捕获受检异常时，必须保留原始异常的栈信息，示例代码如下：

  try {
      // 执行文件读取或JSON解析操作
  } catch (IOException | JsonProcessingException e) {
      throw new TestResourceLoadException("测试依赖资源加载失败", e);
  }
  

  这样能完整保留错误的根因，避免排查时丢失关键信息。
• 只转换不可恢复的受检异常：如果某些受检异常存在恢复可能（比如临时网络波动），可以考虑单独处理，但你场景中的文件读取、JSON解析属于测试基础资源问题，无恢复必要，适合转换。
• 保持框架内处理逻辑一致：所有基础方法的受检异常处理方式要统一，避免出现部分转换、部分直接抛出的混乱情况。

内容的提问来源于stack exchange，提问作者jasonj2232