但这不是那么简单–受检查的异常使代码变得“丑陋”。 它们迫使开发人员编写try / catch块或重新抛出异常。 但是重新抛出隐藏了另一个问题–一些异常不应跨越模块边界。 当您不知道要做什么时，被迫捕获一个已检查的异常时，最常见的做法是将其包装在RuntimeException中并重新抛出。
实际上，这可能不是最常见的-尤其是新手程序员倾向于吞下带有空catch块的异常。 如果存在一些用于异常处理的常规层，则日志和重新抛出有时会导致堆栈跟踪加倍。 无论如何，这里有多种不良做法，导致难以调试和维护的代码。
有人说，鉴于检查过的异常所带来的冗长，繁琐和容易出错，应该彻底消除它们。 C＃根本没有检查过的异常。 当然，消除它们应该考虑向后兼容性。
但是，我认为拥有这两种例外的决定具有其优点。 它迫使开发人员认为在这种情况下可能会发生异常，因此他必须采取措施。 API声明它将抛出异常，并且开发人员将看到此编译时 。 它增强了编译时的安全性。 您不应该等到代码投入生产后才发现可能会失败。 Javadoc？ 好吧，这是一个不错的选择，但是我敢打赌，直到异常发生之前，没有人会阅读javadoc。
那么，如何拥有“两全其美”呢？ 我有一个奇怪的想法（ 请在此处详细说明 ），使API定义两个接口（通过继承链接，因此实际上仅支持一个接口），并提供一种通过工厂获得方法的方法，该实现的方法被检查异常，或将检查的异常包装为未检查的异常。 我不知道这可能是可行的，也可能是愚蠢的。 现在，它看起来很奇怪。
但是以上只是一个解决方法。 然后另一个想法来了–在方法上引入@RethrowExceptions批注。 它会告诉编译器，在此方法中，您不想处理已检查的异常，但也不想声明将其抛出。 （注释的名称可以改进）。 在我想到的最简单的实现中，这可以简单地告诉编译器使用try {..} catch (Exception ex) { throw new RuntimeException(ex);}包围整个方法主体。 好处：
- 编译器仍然警告您使用的方法可能会引发异常，因此您必须考虑处理它
- 通过不必要的尝试/捕获，您不会使代码变得丑陋。 而且您不会强迫呼叫者考虑如何处理例外情况
- 吞下异常的可能性降低了。
简而言之，这样的注释会将方法标记为无法处理异常并且不希望将此决定传播给调用者的方法。
这个想法听起来不那么奇怪。 我猜它现在甚至可以使用编译器插件来实现。 还是已经在lombok项目中实现了？
别忘了分享！
参考： Bozho的技术博客博客中的JCG合作伙伴 Bozhidar Bozhanov提供的 Java中的Checked和Unchecked异常 。
翻译自: https://www.javacodegeeks.com/2012/09/checked-and-unchecked-exceptions-in-java.html
