程序员需要知道一个方法可能抛出的所有异常，以便正确地使用它。因此，仅仅用一些异常来打击他并不一定能帮助一个粗心的程序员避免错误。

微小的好处被繁重的成本所抵消(特别是在较大、不太灵活的代码库中，不断修改接口签名是不切实际的)。

Static analysis can be nice, but truly reliable static analysis often inflexibly demands strict work from the programmer. There is a cost-benefit calculation, and the bar needs to be set high for a check that leads to a compile time error. It would be more helpful if the IDE took on the role of communicating which exceptions a method may throw (including which are unavoidable). Although perhaps it would not be as reliable without forced exception declarations, most exceptions would still be declared in documentation, and the reliability of an IDE warning is not so crucial.

好吧，这不是关于显示堆栈跟踪或无声崩溃。它是关于在层与层之间沟通错误的能力。

The problem with checked exceptions is they encourage people to swallow important details (namely, the exception class). If you choose not to swallow that detail, then you have to keep adding throws declarations across your whole app. This means 1) that a new exception type will affect lots of function signatures, and 2) you can miss a specific instance of the exception you actually -want- to catch (say you open a secondary file for a function that writes data to a file. The secondary file is optional, so you can ignore its errors, but because the signature throws IOException, it's easy to overlook this).

实际上，我现在在一个应用程序中处理这种情况。我们将异常重新打包为AppSpecificException。这使得签名非常干净，我们不必担心在签名中爆炸。

当然，现在我们需要在更高的级别上专门化错误处理，实现重试逻辑等等。所有的东西都是AppSpecificException，所以我们不能说“如果一个IOException被抛出，重试”或“如果ClassNotFound被抛出，完全中止”。我们没有可靠的方法来获得真正的异常，因为当它们在我们的代码和第三方代码之间传递时，东西会一次又一次地重新打包。

这就是为什么我非常喜欢python中的异常处理。你只能捕获你想要和/或能处理的东西。其他所有东西都冒出来了，就好像你自己重新扔了它一样(不管怎样你已经这么做了)。

我一次又一次地发现，在我提到的整个项目中，异常处理分为3类:

Catch and handle a specific exception. This is to implement retry logic, for example. Catch and rethrow other exceptions. All that happens here is usually logging, and its usually a trite message like "Unable to open $filename". These are errors you can't do anything about; only a higher levels knows enough to handle it. Catch everything and display an error message. This is usually at the very root of a dispatcher, and all it does it make sure it can communicate the error to the caller via a non-Exception mechanism (popup dialogue, marshaling an RPC Error object, etc).

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

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)

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

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

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

这篇文章是我读过的关于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设计，无论是在一些Java类中还是在他们自己的类中。

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

我想我读过和你一样的布鲁斯·埃克尔的采访，它总是困扰着我。事实上，这个观点是由。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) */}