1)不，NumberFormatException是一个未检查的异常。即使你发现了它(你不需要)，因为它是未检查的。这是因为它是IllegalArgumentException的子类，而IllegalArgumentException是RuntimeException的子类。

2) RuntimeException是所有未检查异常的根。RuntimeException的每个子类都未选中。所有其他异常和Throwable都被检查，除了错误(属于Throwable)。

3/4)你可以提醒用户他们选择了一个不存在的文件，并要求一个新的文件。或者停止通知用户他们输入了无效的内容。

5)抛出并捕获“异常”是不好的做法。但更一般地，您可能会抛出其他异常，以便调用者可以决定如何处理它。例如，如果您编写了一个库来处理读取一些文件输入，而您的方法被传递给一个不存在的文件，您不知道如何处理它。打电话的人是想再问一次还是想退出?因此，您将异常沿链向上抛出给调用者。

在许多情况下，出现未检查的异常是因为程序员没有验证输入(例如您的第一个问题中的NumberFormatException)。这就是为什么捕获它们是可选的，因为有更优雅的方法来避免生成这些异常。

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

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

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

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

许多人说检查异常(即你应该显式地捕获或重新抛出的异常)根本不应该使用。例如，它们在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.

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

运行时异常: 运行时异常被称为未检查的异常。所有其他例外 是受控异常，并且它们不是派生自java.lang.RuntimeException。

检查异常: 必须在代码中的某个地方捕获受控异常。如果您调用 方法，该方法引发已检查异常，但您没有捕获该已检查异常 在某些地方，您的代码将无法编译。这就是为什么他们被称为检查 异常:编译器检查以确保它们被处理或声明。

Java API中的许多方法都会抛出检查过的异常，因此您将经常编写异常处理程序来处理由您没有编写的方法生成的异常。

我认为受控异常对于使用外部库的开发人员是一个很好的提醒，在异常情况下，该库中的代码可能会出错。

上述异常是否被认为是受控异常? 没有 如果异常是RuntimeException，那么您正在处理的异常并不会使其成为Checked exception。 RuntimeException是未检查的异常吗? 是的

受控异常是java.lang.Exception的子类 未检查异常是java.lang.RuntimeException的子类

抛出已检查异常的调用需要包含在try{}块中，或者在方法调用方的更高级别中处理。在这种情况下，当前方法必须声明它抛出上述异常，以便调用者可以做出适当的安排来处理异常。

希望这能有所帮助。

问:我应该把确切的泡沫 异常或屏蔽它使用异常?

A:是的，这是一个非常好的问题，也是重要的设计考虑因素。Exception类是一个非常通用的异常类，可用于包装内部低级异常。您最好创建一个自定义异常，并将其封装在其中。但是，还有一个很大的问题——永远不要模糊潜在的根本原因。对于前任，不要做下面的事情

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

你可以这样做:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

对生产支持团队来说，消除原始的根本原因，掩盖无法恢复的实际原因是一场噩梦，因为他们只能访问应用程序日志和错误消息。 虽然后者是一种更好的设计，但许多人不经常使用它，因为开发人员无法将底层消息传递给调用者。因此，请明确指出:无论是否封装在任何特定于应用程序的异常中，始终将实际异常传递回去。

在尝试捕获runtimeexception时

runtimeexception作为一般规则不应该被尝试捕获。它们通常是一个编程错误的信号，应该被置之不理。相反，程序员应该在调用一些可能导致RuntimeException的代码之前检查错误条件。为例:

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

这是一种糟糕的编程实践。相反，null检查应该像-那样执行

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

但有时这种错误检查是昂贵的，例如数字格式，考虑这个-

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

在这里，预调用错误检查不值得花费精力，因为它本质上意味着复制parseInt()方法中的所有字符串到整数转换代码——如果由开发人员实现，则很容易出错。因此，最好是取消try-catch。

因此NullPointerException和NumberFormatException都是runtimeexception，捕获一个NullPointerException应该替换为一个优雅的空检查，而我建议显式捕获NumberFormatException以避免可能引入容易出错的代码。