将选中的异常设置为RuntimeException

Question

我正在开发一个遗留系统，它有一个自定义的异常，到处都使用gosh frickity。它受到了ServletException类的启发，该类表示“好的，每当您的Servlet中出现异常时，您都会希望抛出此ServletException”。

随着系统的发展（超过10年），一个在更高级别捕获异常的更强大的系统已经出现，不再需要将每个异常都包装在这个自定义异常中。（有人可能会说从来没有，但那是另一回事。这是一个稳定的应用程序，所以我不会抱怨太多！！）但我们不会一次重构它们，只是随着时间的推移慢慢重构。

然而，有一件事会让事情变得更简单，那就是如果自定义异常是运行时异常而不是检查异常。这样，我们就不需要在任何地方显式地捕获它，并且尚未重构的遗留代码将继续抛出它，就像如果发生空指针异常一样。

我的问题是...接受一次检查的异常并使其成为运行时异常的副作用是什么？

除了对不必要的检查和抛出声明的警告之外，我想不出还有什么，但如果能从以前走过这条路的人那里得到意见，那就太好了。

Answer 1

这里有几个我能想到的

• 运行时异常可能会转移到您不打算转移的层。
  • 示例：Servlet---
  • 如果序列图看起来像A类--

  在我看来，作为一般的拇指法则：

  • 当您“期望”异常作为正常控制流的一部分并知道如何处理时，请使用检查异常。例如：业务规则的验证说帐户余额必须比借方金额至少大100。
  • 使用未经检查的异常时，你不期望异常作为正常控制流的一部分，因此没有办法处理它，但你知道你的层中的某个类会处理它，以确保优雅的降级。
  • 永远不要使用错误。只有JRE有理由抛出错误。

Answer 2

类似的事情发生在我必须维护的应用程序的旧模块上。将异常转换为运行时的唯一问题是您可能会丢失颗粒度，但这完全取决于您来处理。

例如，我们在深层有大量这样的代码：

catch(IOException e){    
    Throwables.propagate(e);
}

我们在该层上粗心地使用了这种模式，当我们需要检查异常原因时，我们总是必须得到异常原因，这在更高层中制造了很多样板文件。直到今天，我认为最好创建一个良好的未检查异常的类层次结构，以保持颗粒度。

catch(IOException e){
    throw new FileNotCreatedException(e);
}

有了这个，您可以在其他层中轻松捕获异常并轻松划分错误和回退：

catch(FileNotCreatedException e){
   notifyError(e);
} catch(NoMoreStorageException e){
   releaseSomeStorage();
   retryOperation();
}

Answer 3

将已检查的异常更改为未检查的异常对现有的工作代码几乎没有实际影响，但您确实需要注意在代码中的某个地方捕获（RuntimeException…）的可能性 。这样的捕获现在不会截获您的自定义异常，但如果您将其取消选中，则会截获。

如果您做了任何与抛出该异常的方法（显然是其中的大多数）相关的反思，您也可能会遇到问题。