Ok... Checked exceptions are not ideal and have some caveat but they do serve a purpose. When creating an API there are specific cases of failures that are contractual of this API. When in the context of a strongly statically typed language such as Java if one does not use checked exceptions then one must rely on ad-hoc documentation and convention to convey the possibility of error. Doing so removes all benefit that the compiler can bring in handling error and you are left completely to the good will of programmers.

因此，一个人删除了Checked异常，比如在c#中所做的，那么如何以编程和结构的方式传达错误的可能性呢?如何通知客户端代码，这样那样的错误可能发生，必须处理?

在处理受控异常时，我听到了各种可怕的事情，它们被滥用了，这是肯定的，但未受控异常也是如此。我说，等几年，当api被堆叠在很多层的时候，你会乞求某种结构化的方法来传达失败。

以异常在API层底部某处抛出的情况为例，因为没有人知道这个错误甚至可能发生，即使它是一种非常合理的错误类型，当调用代码抛出它时(例如FileNotFoundException而不是VogonsTrashingEarthExcept…)在这种情况下，我们是否处理它并不重要，因为没有任何东西可以处理它)。

Many have argued that not being able to load the file was almost always the end of the world for the process and it must die a horrible and painful death. So yeah.. sure ... ok.. you build an API for something and it loads file at some point... I as the user of said API can only respond... "Who the hell are you to decide when my program should crash !" Sure Given the choice where exceptions are gobbled up and leave no trace or the EletroFlabbingChunkFluxManifoldChuggingException with a stack trace deeper than the Marianna trench I would take the latter without a cinch of hesitation, but does this mean that it is the desirable way to deal with exception ? Can we not be somewhere in the middle, where the exception would be recast and wrapped each time it traversed into a new level of abstraction so that it actually means something ?

最后，我看到的大多数争论都是“我不想处理异常，许多人不想处理异常。受控异常迫使我去处理它们，因此我讨厌受控异常。”完全消除这种机制并将其降级到地狱的深渊是愚蠢的，缺乏判断力和远见。

如果我们消除了受控异常，我们也可以消除函数的返回类型，并且总是返回一个“anytype”变量……这样生活就简单多了，不是吗?

这个问题

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

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

最后一点

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

我最初同意你的观点，因为我一直支持受控异常，并开始思考为什么我不喜欢在. net中没有受控异常。但后来我意识到我并不喜欢受控异常。

回答您的问题，是的，我喜欢我的程序显示堆栈跟踪，最好是非常难看的跟踪。我希望应用程序爆发成一堆您希望看到的最糟糕的错误消息。

原因是，如果出现这种情况，我必须修复它，而且必须马上修复。我想马上知道有什么问题。

您实际处理了多少次异常?我说的不是捕获异常——我说的是处理异常?这样写太简单了:

try {
  thirdPartyMethod();
} catch(TPException e) {
  // this should never happen
}

我知道你可能会说这是一种糟糕的实践，“答案”是做一些异常(让我猜猜，记录它?)，但在现实世界(tm)中，大多数程序员就是不这样做。

所以，是的，我不想捕捉异常，如果我没有必要这样做，我希望我的程序在我搞砸的时候爆炸。默默的失败是最糟糕的结果。

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

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

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.

良好的证明Checked Exception是不需要的:

A lot of framework that does some work for Java. Like Spring that wraps JDBC exception to unchecked exceptions, throwing messages to the log Lot of languages that came after java, even on top on java platform - they do not use them Checked exceptions, it is kind prediction about how the client would use the code that throws an exception. But a developer who writes this code would never know about the system and business that client of code is working in. As an example Interfcace methods that force to throw checked exception. There are 100 implementation over the system, 50 or even 90 of implementations do not throw this exception, but the client still must to catch this exception if he user reference to that interface. Those 50 or 90 implementations tend to handle those exceptions inside themself, putting exception to the log (and this is good behavior for them). What we should do with that? I would better have some background logic that would do all that job - sending message to the log. And If I, as a client of code, would feel I need handle the exception - I will do it. I may forget about it, right - but if I use TDD, all my steps are covered and I know what I want. Another example when I'm working with I/O in java, it forces me to check all exception, if file does not exists? what I should do with that? If it does not exists, the system would not go to the next step. The client of this method, would not get expected content from that file - he can handle Runtime Exception, otherwise I should first check Checked Exception, put a message to log, then throw exception up out form the method. No...no - I would better do it automatically with RuntimeEception, that does it / lits up automatically. There is no any sense to handle it manually - I would be happy I saw an error message in the log (AOP can help with that.. something that fixes java). If, eventually, I deice that system should shows pop-up message to the end user - I will show it, not a problem.

我很高兴java能让我选择使用什么，当使用核心库时，比如I/O。Like提供了相同类的两个副本——一个用RuntimeEception包装。然后我们可以比较人们会使用什么。但是现在，很多人会选择java或其他语言之上的框架。比如Scala, JRuby等等。许多人相信SUN是对的。

试图解决这个尚未解决的问题:

如果抛出RuntimeException子类而不是Exception子类，那么您如何知道应该捕获什么?

恕我直言，这个问题包含似是而非的推理。仅仅因为API告诉你它抛出了什么并不意味着你在所有情况下都以相同的方式处理它。 换句话说，您需要捕获的异常取决于您使用抛出异常的组件的上下文。

例如:

如果我正在为数据库编写连接测试程序，或者编写检查用户输入XPath的有效性的程序，那么我可能希望捕获并报告操作抛出的所有已检查和未检查的异常。

然而，如果我正在编写一个处理引擎，我可能会以与NPE相同的方式处理XPathException (checked):我将让它运行到工作线程的顶部，跳过该批处理的其余部分，记录问题(或将其发送给支持部门进行诊断)，并为用户联系支持人员留下反馈。