正如人们已经说过的，Java字节码中不存在受控异常。它们只是一种编译器机制，与其他语法检查没有什么不同。我看到很多受控异常，就像我看到编译器抱怨一个冗余的条件:if(true) {a;b;}。这很有帮助，但我可能是故意这么做的，所以我忽略你的警告。

事实是，如果你强制执行受控异常，你将无法强迫每个程序员“做正确的事情”，而其他人现在都是附带损害，他们只是因为你制定的规则而讨厌你。

修复坏程序!不要试图修改语言来阻止它们!对于大多数人来说，“对异常做一些事情”实际上只是告诉用户它。我也可以告诉用户一个未检查的异常，所以不要让您的已检查异常类出现在我的API中。

我在c2.com上写的文章与原来的CheckedExceptionsAreIncompatibleWithVisitorPattern基本没有变化

总而言之:

访问者模式(Visitor Pattern)及其亲属是一类接口，其中间接调用者和接口实现都知道异常，但接口和直接调用者组成了一个不知道异常的库。

CheckedExceptions的基本假设是，所有声明的异常都可以从调用带有该声明的方法的任何点抛出。VisitorPattern揭示了这个假设是错误的。

在这种情况下，受控异常的最终结果是大量无用的代码，本质上是在运行时删除编译器的受控异常约束。

至于根本问题:

我的总体想法是，顶级处理程序需要解释异常并显示适当的错误消息。我几乎总是看到IO异常、通信异常(由于某些原因api可以区分)或任务致命错误(程序错误或备份服务器上的严重问题)，所以如果我们允许对严重的服务器问题进行堆栈跟踪，这应该不会太难。

在过去的三年中，我一直在与一些开发人员一起开发相对复杂的应用程序。我们有一个代码库，它经常使用检查异常，并进行适当的错误处理，而其他一些代码库则没有。

So far, I have it found easier to work with the code base with Checked Exceptions. When I am using someone else's API, it is nice that I can see exactly what kind of error conditions I can expect when I call the code and handle them properly, either by logging, displaying or ignoring (Yes, there is valid cases for ignoring exceptions, such as a ClassLoader implementation). That gives the code I am writing an opportunity to recover. All runtime exceptions I propagate up until they are cached and handled with some generic error handling code. When I find a checked exception that I don't really want to handle at a specific level, or that I consider a programming logic error, then I wrap it into a RuntimeException and let it bubble up. Never, ever swallow an exception without a good reason (and good reasons for doing this are rather scarce)

当我使用没有检查异常的代码库时，它使我在调用函数时很难预先知道我期望什么，这可能会严重破坏一些东西。

当然，这完全取决于开发者的偏好和技能。编程和错误处理的两种方式可能同样有效(或无效)，所以我不会说只有一种方法。

总而言之，我发现使用受控异常更容易，特别是在有很多开发人员的大型项目中。

下面是反对受控异常的一个论点(来自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.

我想我读过和你一样的布鲁斯·埃克尔的采访，它总是困扰着我。事实上，这个观点是由。net和c#背后的微软天才Anders Hejlsberg(如果这确实是你在谈论的帖子的话)提出的。

http://www.artima.com/intv/handcuffs.html

虽然我是海尔斯伯格和他的作品的粉丝，但我一直认为这种观点是虚假的。基本上可以归结为:

“受控异常很糟糕，因为程序员只是滥用它们，总是捕获它们并忽略它们，这导致问题被隐藏和忽略，否则将呈现给用户”。

通过“以其他方式呈现给用户”，我的意思是如果你使用了一个运行时异常，懒惰的程序员会忽略它(而不是用空的catch块捕获它)，用户会看到它。

这个论点的总结是“程序员不会正确地使用它们，而不正确地使用它们比没有它们更糟糕”。

这种说法有一定道理，事实上，我怀疑Goslings不把运算符重写放在Java中的动机也是出于类似的理由——它们让程序员感到困惑，因为它们经常被滥用。

但最终，我发现这是海尔斯伯格的一个虚假论点，可能是一个事后的论点，用来解释这种缺乏，而不是一个经过深思熟虑的决定。

我想说的是，过度使用受控异常是一件坏事，容易导致用户处理草率，但是正确使用受控异常可以让API程序员给API客户端程序员带来巨大的好处。

现在API程序员必须小心不要到处抛出检查过的异常，否则它们只会惹恼客户端程序员。非常懒惰的客户端程序员将求助于catch (Exception){}，正如Hejlsberg警告的那样，所有的好处都将失去，地狱将随之而来。 但在某些情况下，没有什么可以替代良好的受控异常。

For me, the classic example is the file-open API. Every programming language in the history of languages (on file systems at least) has an API somewhere that lets you open a file. And every client programmer using this API knows that they have to deal with the case that the file they are trying to open doesn't exist. Let me rephrase that: Every client programmer using this API should know that they have to deal with this case. And there's the rub: can the API programmer help them know they should deal with it through commenting alone or can they indeed insist the client deal with it.

在C语言中，这个习语是这样的

  if (f = fopen("goodluckfindingthisfile")) { ... } 
  else { // file not found ...

其中fopen通过返回0指示失败，而C(愚蠢地)让您将0视为布尔值和…基本上，你学会了这个习语就没事了。但如果你是个新手，没有学过这个习语呢?然后，当然，你开始用

   f = fopen("goodluckfindingthisfile");
   f.read(); // BANG! 

从艰苦中学习。

请注意，这里我们只讨论强类型语言:对于强类型语言中的API是什么有一个清晰的概念:它是供您使用的功能(方法)的大杂烩，并为每个功能(方法)使用明确定义的协议。

明确定义的协议通常由方法签名定义。 这里fopen要求你给它传递一个字符串(在C语言中是char*)。如果你给它其他东西，你会得到一个编译时错误。您没有遵循协议—您没有正确地使用API。

在一些(晦涩的)语言中，返回类型也是协议的一部分。如果你试图在某些语言中调用等同于fopen()的函数而不将其赋值给变量，你也会得到一个编译时错误(你只能用void函数来做)。

我想说的是:在静态类型语言中，API程序员鼓励客户端正确使用API，如果客户端代码出现明显错误，就会阻止它被编译。

(在像Ruby这样的动态类型语言中，你可以传递任何东西，比如float，作为文件名——它会被编译。如果你甚至不打算控制方法参数，为什么要用受控异常来麻烦用户呢?这里的参数只适用于静态类型的语言。)

那么，受控异常呢?

这里有一个可以用来打开文件的Java api。

try {
  f = new FileInputStream("goodluckfindingthisfile");
}
catch (FileNotFoundException e) {
  // deal with it. No really, deal with it!
  ... // this is me dealing with it
}

看到了吗?下面是API方法的签名:

public FileInputStream(String name)
                throws FileNotFoundException

注意，FileNotFoundException是一个受控异常。

API程序员对你说: 你可以使用这个构造函数来创建一个新的FileInputStream

A)必须将文件名作为A 字符串 B)必须接受 文件可能不存在的可能性 在运行时被发现”

这就是我所关心的全部。

问题的关键在于问题所表述的“程序员无法控制的事情”。我的第一个想法是他/她指的是API程序员无法控制的东西。但事实上，受控异常在正确使用的情况下，确实应该用于客户端程序员和API程序员都无法控制的事情。我认为这是不滥用受控异常的关键。

我认为文件打开很好地说明了这一点。API程序员知道，您可能会给他们一个在调用API时不存在的文件名，并且他们将无法返回您想要的结果，而必须抛出异常。他们也知道这种情况会经常发生，客户端程序员在编写调用时可能希望文件名是正确的，但在运行时由于他们无法控制的原因也可能是错误的。

因此，API明确了这一点:在某些情况下，当你打电话给我时，这个文件不存在，你最好处理它。

有了反案例，这一点就更清楚了。假设我在写一个表API。我有一个包含这个方法的API的表模型:

public RowData getRowData(int row) 

现在，作为一个API程序员，我知道会有这样的情况:一些客户端会为行传递一个负值，或者在表外传递一个行值。所以我可能会抛出一个受控异常，并迫使客户端处理它:

public RowData getRowData(int row) throws CheckedInvalidRowNumberException

(当然，我不会称之为“检查过”。)

这是对受控异常的错误使用。客户端代码将充满获取行数据的调用，每个调用都必须使用try/catch，用于什么?它们是否会向用户报告查找了错误的行?可能不会，因为无论我的表格视图周围的UI是什么，它都不应该让用户进入一个非法行被请求的状态。所以这是客户端程序员的错误。

API程序员仍然可以预测客户端将编写这样的错误，并且应该用IllegalArgumentException这样的运行时异常来处理它。

对于getRowData中的受控异常，这显然会导致Hejlsberg的懒惰程序员只是添加空捕获。当这种情况发生时，即使对测试人员或客户端开发人员调试，非法行值也不会很明显，相反，它们会导致难以查明来源的直接错误。阿里安火箭发射后会爆炸。

好了，问题来了:我说的是检查异常FileNotFoundException不仅是一个好东西，而且是API程序员工具箱中的一个基本工具，它可以以对客户端程序员最有用的方式定义API。但是CheckedInvalidRowNumberException非常不方便，会导致糟糕的编程，应该避免使用。但是如何区分呢?

我想这并不是一门精确的科学我想这在一定程度上支持了海尔斯伯格的观点。但我不喜欢把孩子和洗澡水一起倒掉，所以请允许我在这里提取一些规则来区分好的受控异常和坏的异常:

Out of client's control or Closed vs Open: Checked exceptions should only be used where the error case is out of control of both the API and the client programmer. This has to do with how open or closed the system is. In a constrained UI where the client programmer has control, say, over all of the buttons, keyboard commands etc that add and delete rows from the table view (a closed system), it is a client programming bug if it attempts to fetch data from a nonexistent row. In a file-based operating system where any number of users/applications can add and delete files (an open system), it is conceivable that the file the client is requesting has been deleted without their knowledge so they should be expected to deal with it. Ubiquity: Checked exceptions should not be used on an API call that is made frequently by the client. By frequently I mean from a lot of places in the client code - not frequently in time. So a client code doesn't tend to try to open the same file a lot, but my table view gets RowData all over the place from different methods. In particular, I'm going to be writing a lot of code like if (model.getRowData().getCell(0).isEmpty())

而且，每次都必须在尝试/捕获中结束，这将是痛苦的。

Informing the User: Checked exceptions should be used in cases where you can imagine a useful error message being presented to the end user. This is the "and what will you do when it happens?" question I raised above. It also relates to item 1. Since you can predict that something outside of your client-API system might cause the file to not be there, you can reasonably tell the user about it: "Error: could not find the file 'goodluckfindingthisfile'" Since your illegal row number was caused by an internal bug and through no fault of the user, there's really no useful information you can give them. If your app doesn't let runtime exceptions fall through to the console it will probably end up giving them some ugly message like: "Internal error occured: IllegalArgumentException in ...." In short, if you don't think your client programmer can explain your exception in a way that helps the user, then you should probably not be using a checked exception.

这就是我的规则。有些刻意，毫无疑问会有例外(如果你愿意，请帮助我完善它们)。但我的主要论点是，在像FileNotFoundException这样的情况下，checked异常是API契约中与参数类型一样重要和有用的一部分。因此，我们不应该仅仅因为它被滥用就放弃它。

抱歉，我不是故意说这么长时间的。最后我想提两点建议:

答:API程序员:谨慎使用受控异常以保持它们的有用性。如果有疑问，请使用未检查的异常。

B:客户端程序员:养成在开发早期创建封装异常(谷歌)的习惯。JDK 1.4及后续版本在RuntimeException中为此提供了一个构造函数，但您也可以轻松地创建自己的构造函数。下面是构造函数:

public RuntimeException(Throwable cause)

然后养成这样的习惯:当您不得不处理受控异常时，您感到懒惰(或者您认为API程序员在第一时间使用受控异常时过于热心)，不要只是吞下异常，包装它并重新抛出它。

try {
  overzealousAPI(thisArgumentWontWork);
}
catch (OverzealousCheckedException exception) {
  throw new RuntimeException(exception);  
}

把它放在IDE的一个小代码模板中，当你觉得懒的时候就可以使用它。这样，如果您真的需要处理检查异常，那么在运行时看到问题后，您将被迫返回并处理它。因为，相信我(和安德斯·海尔斯伯格)，你永远不会回到你的TODO

catch (Exception e) { /* TODO deal with this at some point (yeah right) */}

这个问题

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

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

最后一点

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