多年来，我一直无法得到以下问题的一个像样的答案:为什么一些开发人员如此反对受控异常?我有过无数次的对话，在博客上读过一些东西，读过Bruce Eckel说的话(我看到的第一个站出来反对他们的人)。
我目前正在编写一些新代码，并非常注意如何处理异常。我试图了解那些“我们不喜欢受控异常”的人的观点，但我仍然看不出来。
我的每一次谈话都以同样的问题结束。让我把它建立起来:
一般来说(从Java的设计方式来看)，
Error is for things that should never be caught (VM has a peanut allergy and someone dropped a jar of peanuts on it)
RuntimeException is for things that the programmer did wrong (programmer walked off the end of an array)
Exception (except RuntimeException) is for things that are out of the programmer's control (disk fills up while writing to the file system, file handle limit for the process has been reached and you cannot open any more files)
Throwable is simply the parent of all of the exception types.
我听到的一个常见的说法是，如果发生了异常，那么所有开发人员要做的就是退出程序。
我听到的另一个常见论点是受控异常使得重构代码更加困难。
对于“我要做的就是退出”的参数，我说即使你退出了，你也需要显示一个合理的错误消息。如果你只是在处理错误上押注，那么当程序在没有明确说明原因的情况下退出时，你的用户不会太高兴。
对于“它使重构变得困难”的人群来说，这表明没有选择适当的抽象级别。与其声明方法抛出IOException，不如将IOException转换为更适合当前情况的异常。
我对用catch(Exception)(或在某些情况下用catch(Throwable)包装Main没有问题，以确保程序可以优雅地退出-但我总是捕获我需要的特定异常。这样做至少可以显示适当的错误消息。
人们从来不会回答的问题是:
如果抛出RuntimeException
子类代替异常
子类，你怎么知道
你应该去抓?
如果答案是catch Exception，那么您也在以与系统异常相同的方式处理程序员错误。在我看来这是不对的。
如果你捕获Throwable，那么你是在以同样的方式处理系统异常和虚拟机错误(等等)。在我看来这是不对的。
如果答案是您只捕获您知道抛出的异常，那么您如何知道抛出了哪些异常呢?当程序员X抛出一个新的异常而忘记捕获它时会发生什么?这对我来说似乎很危险。
我认为显示堆栈跟踪的程序是错误的。不喜欢受控异常的人不会有这种感觉吗?
所以，如果你不喜欢受控异常，你能解释一下为什么不，并回答没有得到回答的问题吗?
我不是在寻求什么时候使用这两种模型的建议，我想知道的是为什么人们从RuntimeException扩展，因为他们不喜欢从Exception扩展，和/或为什么他们捕获一个异常然后重新抛出一个RuntimeException，而不是将抛出添加到他们的方法中。我想了解不喜欢受控异常的动机。
这个问题
我所看到的异常处理机制最糟糕的问题是它引入了大规模的代码复制!让我们诚实地说:在大多数项目中，在95%的时间里，开发人员真正需要做的就是以某种方式与用户沟通(在某些情况下，也需要与开发团队沟通，例如通过发送带有堆栈跟踪的电子邮件)。因此，通常在处理异常的每个地方都使用相同的代码行/块。
让我们假设我们在每个catch块中对某种类型的检查异常做简单的日志记录:
try{
methodDeclaringCheckedException();
}catch(CheckedException e){
logger.error(e);
}
如果这是一个常见的异常，那么在更大的代码库中甚至可能有数百个这样的try-catch块。现在让我们假设我们需要引入基于弹出对话框的异常处理，而不是控制台日志记录，或者开始额外向开发团队发送电子邮件。
等一下……我们真的要在代码中编辑这几百个位置吗?你明白我的意思:-)。
解决方案
为了解决这个问题，我们引入了异常处理程序的概念(我将进一步将其称为EH)来集中异常处理。对于每个需要处理异常的类，依赖注入框架都会注入一个异常处理程序实例。所以异常处理的典型模式现在看起来像这样:
try{
methodDeclaringCheckedException();
}catch(CheckedException e){
exceptionHandler.handleError(e);
}
现在要定制我们的异常处理，我们只需要更改一个地方的代码(EH代码)。
当然，对于更复杂的情况，我们可以实现eh的几个子类，并利用DI框架提供给我们的特性。通过改变我们的DI框架配置，我们可以轻松地在全局切换EH实现，或者为有特殊异常处理需求的类提供特定的EH实现(例如使用Guice @Named注释)。
这样我们就可以区分应用程序的开发版本和发布版本中的异常处理行为。开发——记录错误并停止应用程序，用更详细的信息刺激记录错误并让应用程序继续执行)。
最后一点
最后但并非最不重要的是，似乎可以通过将异常“向上传递”直到它们到达某个顶级异常处理类来获得同样的集中化。但这会导致代码和方法签名的混乱，并引入本线程中其他人提到的维护问题。
这个问题
我所看到的异常处理机制最糟糕的问题是它引入了大规模的代码复制!让我们诚实地说:在大多数项目中，在95%的时间里，开发人员真正需要做的就是以某种方式与用户沟通(在某些情况下，也需要与开发团队沟通，例如通过发送带有堆栈跟踪的电子邮件)。因此，通常在处理异常的每个地方都使用相同的代码行/块。
让我们假设我们在每个catch块中对某种类型的检查异常做简单的日志记录:
try{
methodDeclaringCheckedException();
}catch(CheckedException e){
logger.error(e);
}
如果这是一个常见的异常，那么在更大的代码库中甚至可能有数百个这样的try-catch块。现在让我们假设我们需要引入基于弹出对话框的异常处理，而不是控制台日志记录，或者开始额外向开发团队发送电子邮件。
等一下……我们真的要在代码中编辑这几百个位置吗?你明白我的意思:-)。
解决方案
为了解决这个问题，我们引入了异常处理程序的概念(我将进一步将其称为EH)来集中异常处理。对于每个需要处理异常的类，依赖注入框架都会注入一个异常处理程序实例。所以异常处理的典型模式现在看起来像这样:
try{
methodDeclaringCheckedException();
}catch(CheckedException e){
exceptionHandler.handleError(e);
}
现在要定制我们的异常处理，我们只需要更改一个地方的代码(EH代码)。
当然，对于更复杂的情况，我们可以实现eh的几个子类，并利用DI框架提供给我们的特性。通过改变我们的DI框架配置，我们可以轻松地在全局切换EH实现，或者为有特殊异常处理需求的类提供特定的EH实现(例如使用Guice @Named注释)。
这样我们就可以区分应用程序的开发版本和发布版本中的异常处理行为。开发——记录错误并停止应用程序，用更详细的信息刺激记录错误并让应用程序继续执行)。
最后一点
最后但并非最不重要的是，似乎可以通过将异常“向上传递”直到它们到达某个顶级异常处理类来获得同样的集中化。但这会导致代码和方法签名的混乱，并引入本线程中其他人提到的维护问题。
这篇文章是我读过的关于Java异常处理的最好的文章。
它更倾向于未检查的异常，而不是已检查的异常，但这个选择的解释非常透彻，并基于强有力的论据。
我不想在这里引用太多的文章内容(最好是整体阅读)，但它涵盖了这个线程中未检查异常倡导者的大部分论点。尤其是这个论点(似乎很受欢迎):
以异常在API层底部某处抛出的情况为例，因为没有人知道这个错误甚至可能发生，即使它是一种非常合理的错误类型，当调用代码抛出它时(例如FileNotFoundException而不是VogonsTrashingEarthExcept…)在这种情况下，我们是否处理它并不重要，因为没有任何东西可以处理它)。
作者“回应”:
It is absolutely incorrect to assume that all runtime exceptions
should not be caught and allowed to propagate to the very "top" of the
application. (...) For every exceptional condition that is required to
be handled distinctly - by the system/business requirements -
programmers must decide where to catch it and what to do once the
condition is caught. This must be done strictly according to the
actual needs of the application, not based on a compiler alert. All
other errors must be allowed to freely propagate to the topmost
handler where they would be logged and a graceful (perhaps,
termination) action will be taken.
主要的思想或文章是:
当涉及到软件中的错误处理时，唯一安全且正确的假设是，存在的每个子程序或模块都可能发生故障!
因此，如果“没有人知道这个错误甚至可能发生”，那么这个项目就有问题了。像作者建议的那样，这种异常至少应该由最通用的异常处理程序来处理(例如，处理所有没有更特定的处理程序处理的异常)。
很遗憾，似乎没有多少人发现这篇伟大的文章:-(。我衷心建议每一个犹豫哪种方法更好的人花点时间阅读它。
简而言之:
异常是一个API设计问题。——不多不少。
检查异常的参数:
为了理解受控异常为什么不是好事，让我们把问题转过来问:受控异常什么时候或为什么有吸引力，也就是说，为什么你希望编译器强制声明异常?
答案是显而易见的:有时您需要捕获异常，而这只有在被调用的代码为您感兴趣的错误提供了特定的异常类时才有可能。
因此，受控异常的理由是，编译器强迫程序员声明抛出了哪些异常，希望程序员随后也会记录特定的异常类和导致异常的错误。
但在现实中，往往是一个包装。acme只抛出AcmeException而不抛出特定的子类。然后调用者需要处理、声明或重新发出acmeexception信号，但仍然不能确定是发生了AcmeFileNotFoundError还是发生了AcmePermissionDeniedError。
因此，如果您只对AcmeFileNotFoundError感兴趣，解决方案是向ACME程序员提交一个特性请求，并告诉他们实现、声明和记录AcmeException的子类。
所以为什么要麻烦呢?
因此，即使使用受控异常，编译器也不能强迫程序员抛出有用的异常。这仍然只是API质量的问题。
因此，没有受控异常的语言通常情况不会更糟。程序员可能倾向于抛出一般Error类的非特定实例，而不是AcmeException，但如果他们完全关心API质量，他们终究会学会引入AcmeFileNotFoundError。
总的来说，异常的规范和文档与普通方法的规范和文档没有太大的区别。这些也是一个API设计问题，如果程序员忘记实现或导出一个有用的特性，那么API就需要改进，以便您可以有效地使用它。
如果遵循这条推理线，很明显，在Java等语言中非常常见的声明、捕获和重新抛出异常的“麻烦”通常没有什么价值。
同样值得注意的是，Java VM没有检查过的异常——只有Java编译器检查它们，并且在运行时，类文件的异常声明更改后是兼容的。Java虚拟机的安全性并不是通过受控异常来提高的，而是通过编码风格来提高的。
