关于未检查异常和已检查异常之间的区别，我最喜欢的描述来自Java教程的试用文章“未检查异常-争议”(很抱歉在这篇文章中介绍了所有基本的内容-但是，嘿，基本的有时是最好的):

这是底线原则:如果客户可以合理地 希望从异常中恢复，使其成为受控异常。如果 客户端不能做任何事情来从异常中恢复 未经检查的异常

“抛出哪种类型的异常”的核心是语义的(在某种程度上)，上面的引用提供了一个很好的指导方针(因此，我仍然被c#摆脱受控异常的概念所震撼——特别是Liskov认为它们有用)。

接下来的问题就变得合乎逻辑了:编译器希望我显式地响应哪些异常?你希望客户能从中恢复过来。

Java distinguishes between two categories of exceptions (checked & unchecked). Java enforces a catch or declared requirement for checked exceptions. An exception's type determines whether an exception is checked or unchecked. All exception types that are direct or indirect subclasses of class RuntimeException are unchecked exception. All classes that inherit from class Exception but not RuntimeException are considered to be checked exceptions. Classes that inherit from class Error are considered to be unchecked. Compiler checks each method call and deceleration to determine whether the method throws checked exception. If so the compiler ensures the exception is caught or is declared in a throws clause. To satisfy the declare part of the catch-or-declare requirement, the method that generates the exception must provide a throws clause containing the checked-exception. Exception classes are defined to be checked when they are considered important enough to catch or declare.

许多人说检查异常(即你应该显式地捕获或重新抛出的异常)根本不应该使用。例如，它们在c#中被淘汰了，大多数语言都没有它们。因此，您总是可以抛出RuntimeException的子类(未检查的异常)

然而，我认为受控异常是有用的——当你想强迫API的用户思考如何处理异常情况(如果它是可恢复的)时，就使用它们。只是受控异常在Java平台中被过度使用了，这让人们讨厌它们。

以下是我对这个话题的扩展观点。

关于具体问题:

Is the NumberFormatException consider a checked exception? No. NumberFormatException is unchecked (= is subclass of RuntimeException). Why? I don't know. (but there should have been a method isValidInteger(..)) Is RuntimeException an unchecked exception? Yes, exactly. What should I do here? It depends on where this code is and what you want to happen. If it is in the UI layer - catch it and show a warning; if it's in the service layer - don't catch it at all - let it bubble. Just don't swallow the exception. If an exception occurs in most of the cases you should choose one of these: log it and return rethrow it (declare it to be thrown by the method) construct a new exception by passing the current one in constructor Now, couldn't the above code also be a checked exception? I can try to recover the situation like this? Can I? It could've been. But nothing stops you from catching the unchecked exception as well Why do people add class Exception in the throws clause? Most often because people are lazy to consider what to catch and what to rethrow. Throwing Exception is a bad practice and should be avoided.

遗憾的是，没有单一的规则可以让您决定何时捕获、何时重新抛出、何时使用已检查异常和何时使用未检查异常。我同意这会导致很多混乱和很多糟糕的代码。布洛赫阐述了总体原则(你引用了其中的一部分)。一般的原则是将异常重新抛出到可以处理它的层。

受控异常在编译时由JVM检查，并与资源相关(文件/db/流/套接字等)。受控异常的动机是，在编译时，如果资源不可用，应用程序应该在catch/finally块中定义一个替代行为来处理这个异常。

未经检查的异常纯粹是编程错误、错误计算、空数据甚至业务逻辑中的失败都可能导致运行时异常。在代码中处理/捕获未检查的异常是绝对没问题的。

解释摘自http://coder2design.com/java-interview-questions/

所有这些都是受控异常。未检查的异常是RuntimeException的子类。问题不在于如何处理它们，而在于你的代码是否应该抛出它们。如果你不想让编译器告诉你你还没有处理一个异常，那么你可以使用一个未检查的(RuntimeException的子类)异常。这些应该保存在你无法恢复的情况下，比如内存不足等。

为了回答最后一个问题(上面的其他问题似乎都得到了彻底的回答)，“我应该冒泡出确切的异常还是使用exception掩盖它?”

我猜你的意思是这样的:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

不，总是声明尽可能精确的异常，或者一个这样的列表。你声明你的方法能够抛出的异常是你的方法和调用者之间契约的一部分。抛出"FileNotFoundException"意味着可能文件名无效，无法找到该文件;调用者需要聪明地处理这个问题。抛出异常意味着“嘿，该死的事情发生了。交易。”这是一个非常糟糕的API。

在第一篇文章的注释中有一些例子，其中“throws Exception”是一个有效且合理的声明，但对于您所编写的大多数“正常”代码来说，情况并非如此。