包装异常

3.包装异常

受检异常在理论上看起来很酷，但在实践中却是一个巨大的挫折。

假设你的项目中有一个超级流行的方法。它从您程序中的数百个地方调用。你决定向它添加一个新的检查异常。很可能这个已检查的异常真的很重要而且很特别，只有main()方法知道如果它被捕获时该怎么做。

这意味着您必须将已检查的异常添加到throws调用您的超级流行方法的每个方法的子句中。以及在throws调用这些方法的所有方法的子句中。以及调用这些方法的方法。

结果，throws项目中一半方法的子句得到了一个新的检查异常。当然，您的项目包含在测试中，现在测试无法编译。现在您还必须在测试中编辑 throws 子句。

然后你的所有代码（数百个文件中的所有更改）都必须由其他程序员审查。在这一点上，我们问自己为什么要对项目进行如此多的血腥更改？一天（几？）的工作，以及失败的测试——所有这些都是为了添加一个检查异常？

当然，仍然存在与继承和方法重写相关的问题。检查异常带来的问题比好处大得多。归根结底，现在很少有人喜欢它们，也很少有人使用它们。

但是，仍然有很多代码（包括标准 Java 库代码）包含这些已检查的异常。他们该怎么办？我们不能忽视它们，我们也不知道如何处理它们。

Java 程序员建议将已检查的异常包装在RuntimeException. 换句话说，捕获所有已检查的异常，然后创建未检查的异常（例如，RuntimeException）并抛出它们。这样做看起来像这样：

try
{
   // Code where a checked exception might occur
}
catch(Exception exp)
{
   throw new RuntimeException(exp);
}

这不是一个非常漂亮的解决方案，但这里没有任何犯罪行为：异常只是被塞进了一个RuntimeException.

如果需要，您可以从那里轻松检索它。例子：

try
{
   // Code where we wrap the checked exception
   // in a RuntimeException
}
catch(RuntimeException e)
{
   Throwable cause = e.getCause();
   if (cause instanceof Exception)
   {
      Exception exp = (Exception) cause;
      // Exception handling code goes here
   }
}