Java 理论与实践: 平衡测试，第 2 部分：编写和优化 bug 检测器

核心提示： 另一方面，异常处理的主要缺陷是：在正确使用异常时，Java 理论与实践: 平衡测试，第 2 部分：编写和优化 bug 检测器(2)，易于建立带有三行或四行业务逻辑以及 20 或 30 行异常处理的方法，因为错误恢复代码在测试时容易出现错误并且执行困难，现在，未经检查的异常将被记录（而不传播），使

另一方面，异常处理的主要缺陷是：在正确使用异常时，易于建立带有三行或四行业务逻辑以及 20 或 30 行异常处理的方法。因为错误恢复代码在测试时容易出现错误并且执行困难，使一部分专门用于异常处理的代码无所适从并容易出错。这种情况的典型示例如清单所示，其中带有两行 “真的” 代码的方法需要三个独立的捕获块，每个捕获块都执行完全相同的操作 —— 记录该异常：

清单 1. 多个相同的捕获块

public　void　addInstance(String　className)　{　
　　try　{　
　　　　Class　clazz　=　Class.forName(className);　
　　　　objectSet.add(clazz.newInstance());　
　　}　
　　catch　(IllegalAccessException　e)　{　
　　　　logger.log("Exception　in　addInstance",　e);　
　　}　
　　catch　(InstantiationException　e)　{　
　　　　logger.log("Exception　in　addInstance",　e);　
　　}　
　　catch　(ClassNotFoundException　e)　{　
　　　　logger.log("Exception　in　addInstance",　e);　
　　}　
}　

请参见清单 1，您可能尝试将三个捕获块合并成捕获 Exception 的单独捕获块，因为每个捕获块的捕获恢复操作是相同的。乍一看，该策略似乎是一个好方法 —— 但代码副本有错误，所以整合这些复制路径应该是一种改进。不过，此 “改进” 常常会带来意想不到的结果。因为 RuntimeException 扩展了 Exception，将三个捕获块合并成一个捕获块（如清单 2 所示），所以这会更改语义，现在，未经检查的异常将被记录（而不传播）。此 bug 模式（其中 RuntimeException 容易被超大捕获块捕获）也称为 RuntimeException 捕获。