Robert C. Martin在他的著作《Clean Code》中也不推荐使用受控异常，他认为受控异常违反了开闭原则:

什么价格?受控异常的价格是Open/Closed Principle1侵犯。如果从方法抛出checked异常 在您的代码中，并且catch高于三级，您必须声明 实例之间的每个方法签名中的异常 抓住。这意味着在软件的低级别上的更改可以 在许多更高级别上强制更改签名。变更的模块 必须重建和重新部署，即使他们不关心 改变了。

这个问题

我所看到的异常处理机制最糟糕的问题是它引入了大规模的代码复制!让我们诚实地说:在大多数项目中，在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注释)。

这样我们就可以区分应用程序的开发版本和发布版本中的异常处理行为。开发——记录错误并停止应用程序，用更详细的信息刺激记录错误并让应用程序继续执行)。

最后一点

最后但并非最不重要的是，似乎可以通过将异常“向上传递”直到它们到达某个顶级异常处理类来获得同样的集中化。但这会导致代码和方法签名的混乱，并引入本线程中其他人提到的维护问题。

我不想重复所有(许多)反对受控异常的原因，我只选一个。我已经记不清写了多少次这段代码了:

try {
  // do stuff
} catch (AnnoyingcheckedException e) {
  throw new RuntimeException(e);
}

99%的情况下我对此无能为力。最后，块进行必要的清理(或者至少它们应该这样做)。

我也记不清有多少次看到这样的场景:

try {
  // do stuff
} catch (AnnoyingCheckedException e) {
  // do nothing
}

为什么?因为有人要处理这件事，而且很懒。错了吗?确定。会发生吗?绝对的。如果这是一个未检查的异常呢?应用程序就会死掉(这比吞下一个异常更好)。

然后我们有一些令人愤怒的代码，它使用异常作为一种流控制形式，就像java.text.Format所做的那样。Bzzzt。错了。用户在表单的数字字段中输入“abc”也不例外。

好吧，我想这是三个原因。

尽管阅读了整页，我仍然找不到一个反对受控异常的合理论点。相反，大多数人都在谈论糟糕的API设计，无论是在一些Java类中还是在他们自己的类中。

这个功能唯一令人讨厌的地方就是原型设计。这可以通过向语言中添加一些机制来解决(例如，一些@supresscheckedexceptions注释)。但是对于常规编程，我认为受控异常是一件好事。

《有效的Java异常》一文很好地解释了什么时候使用未检查的异常，什么时候使用已检查的异常。以下是那篇文章中的一些引语，以突出其要点:

应急预案: 一种期望的条件，要求方法提供可根据该方法的预期目的来表达的替代响应。方法的调用者期望这些类型的条件，并有一个策略来处理它们。 错: 一种计划外的情况，阻止方法实现其预期目的，如果不参考方法的内部实现，则无法描述该情况。

(SO不支持表格，所以你可能想从原始页面阅读以下内容…)

Contingency Is considered to be: A part of the design Is expected to happen: Regularly but rarely Who cares about it: The upstream code that invokes the method Examples: Alternative return modes Best Mapping: A checked exception Fault Is considered to be: A nasty surprise Is expected to happen: Never Who cares about it: The people who need to fix the problem Examples: Programming bugs, hardware malfunctions, configuration mistakes, missing files, unavailable servers Best Mapping: An unchecked exception

下面是反对受控异常的一个论点(来自joelonsoftware.com):

The reasoning is that I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: They are invisible in the source code. Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where. This means that even careful code inspection doesn't reveal potential bugs. They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.