《有效的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

我们已经看到了c#首席架构师的一些参考。

下面是Java人员关于何时使用受控异常的另一种观点。他承认了其他人提到的许多负面因素: 有效的异常

这并不是反对受控异常的纯概念，但是Java用于受控异常的类层次结构是一个畸形秀。我们总是简单地称这些东西为“异常”——这是正确的，因为语言规范也这样称呼它们——但是异常在类型系统中是如何命名和表示的呢?

By the class Exception one imagines? Well no, because Exceptions are exceptions, and likewise exceptions are Exceptions, except for those exceptions that are not Exceptions, because other exceptions are actually Errors, which are the other kind of exception, a kind of extra-exceptional exception that should never happen except when it does, and which you should never catch except sometimes you have to. Except that's not all because you can also define other exceptions that are neither Exceptions nor Errors but merely Throwable exceptions.

哪些是“已检查”异常?可抛出异常是受控异常，除非它们也是错误，是未检查的异常，然后是异常，也是可抛出异常，是受控异常的主要类型，除了有一个例外，那就是if它们也是runtimeexception，因为那是另一种未检查的异常。

What are RuntimeExceptions for? Well just like the name implies, they're exceptions, like all Exceptions, and they happen at run-time, like all exceptions actually, except that RuntimeExceptions are exceptional compared to other run-time Exceptions because they aren't supposed to happen except when you make some silly error, although RuntimeExceptions are never Errors, so they're for things that are exceptionally erroneous but which aren't actually Errors. Except for RuntimeErrorException, which really is a RuntimeException for Errors. But aren't all exceptions supposed to represent erroneous circumstances anyway? Yes, all of them. Except for ThreadDeath, an exceptionally unexceptional exception, as the documentation explains that it's a "normal occurrence" and that that's why they made it a type of Error.

Anyway, since we're dividing all exceptions down the middle into Errors (which are for exceptional execution exceptions, so unchecked) and Exceptions (which are for less exceptional execution errors, so checked except when they're not), we now need two different kinds of each of several exceptions. So we need IllegalAccessError and IllegalAccessException, and InstantiationError and InstantiationException, and NoSuchFieldError and NoSuchFieldException, and NoSuchMethodError and NoSuchMethodException, and ZipError and ZipException.

只不过，即使检查了异常，也总有(相当简单的)方法可以欺骗编译器，在不检查的情况下抛出异常。如果你这样做，你可能会得到一个不确定的throwableexception，除非在其他情况下，它可能抛出一个意外的dexception，或一个未知的异常(与未知的错误无关，只针对“严重的异常”)，或一个ExecutionException，或一个InvocationTargetException，或一个ExceptionInInitializerError。

哦，我们一定不能忘记Java 8时髦的新UncheckedIOException，这是一个RuntimeException异常，设计用来通过包装由I/O错误(不会引起IOError异常，尽管也存在)引起的已检查的IOException异常来抛出异常检查的概念，这些异常异常难以处理，因此您需要它们不被检查。

由于Java !

受控异常的一个问题是，如果一个接口的一个实现使用了它，异常通常会附加到该接口的方法上。

受控异常的另一个问题是它们容易被滥用。java.sql就是一个完美的例子。连接的close()方法。它可以抛出一个SQLException，即使您已经显式地声明您已经完成了连接。close()可能传达了哪些您所关心的信息?

通常，当我关闭()一个连接*时，它看起来像这样:

try {
    conn.close();
} catch (SQLException ex) {
    // Do nothing
}

另外，不要让我开始各种解析方法和NumberFormatException... .NET的TryParse，它不抛出异常，使用起来要容易得多，以至于不得不回到Java(我工作的地方同时使用Java和c#)。

*作为额外的注释，PooledConnection的connection .close()甚至不关闭连接，但您仍然必须捕获SQLException，因为它是一个已检查异常。

Artima发表了一篇对。net架构师之一Anders Hejlsberg的采访，其中尖锐地讨论了反对受控异常的论点。品性差的人:

The throws clause, at least the way it's implemented in Java, doesn't necessarily force you to handle the exceptions, but if you don't handle them, it forces you to acknowledge precisely which exceptions might pass through. It requires you to either catch declared exceptions or put them in your own throws clause. To work around this requirement, people do ridiculous things. For example, they decorate every method with, "throws Exception." That just completely defeats the feature, and you just made the programmer write more gobbledy gunk. That doesn't help anybody.

我读了很多关于异常处理的书，即使(大多数时候)我不能真的说我对受控异常的存在感到高兴或悲伤，这是我的看法:在低级代码(IO，网络，OS等)中受控异常，在高级api /应用程序级别中未受控异常。

即使在它们之间没有那么容易划清界限，我发现在同一屋檐下集成几个api /库而不始终包装大量的检查异常是非常烦人/困难的，但另一方面，有时强制捕获一些异常并提供一个在当前上下文中更有意义的不同异常是有用/更好的。

The project I'm working on takes lots of libraries and integrates them under the same API, API which is completely based on unchecked exceptions.This frameworks provides a high-level API which in the beginning was full of checked exceptions and had only several unchecked exceptions(Initialization Exception, ConfigurationException, etc) and I must say was not very friendly. Most of the time you had to catch or re-throw exceptions which you don't know how to handle, or you don't even care(not to be confused with you should ignore exceptions), especially on the client side where a single click could throw 10 possible (checked) exceptions.

The current version(3rd one) uses only unchecked exceptions, and it has a global exception handler which is responsible to handle anything uncaught. The API provides a way to register exception handlers, which will decide if an exception is considered an error(most of the time this is the case) which means log & notify somebody, or it can mean something else - like this exception, AbortException, which means break the current execution thread and don't log any error 'cause it is desired not to. Of course, in order to work out all custom thread must handle the run() method with a try {...} catch(all).

公共无效运行(){

try {
     ... do something ...
} catch (Throwable throwable) {
     ApplicationContext.getExceptionService().handleException("Handle this exception", throwable);
}

}

如果您使用WorkerService来安排作业(Runnable, Callable, Worker)，这是不必要的，它会为您处理一切。

当然，这只是我的个人观点，它可能不是正确的，但对我来说这是一个很好的方法。我将在发布项目后看看我认为对我有好处的东西，对其他人也有好处……：）