Joshua Bloch在“Effective Java”中说过
对可恢复条件使用已检查的异常，对编程错误使用运行时异常（第2版中的第58项）
让我们看看我是否正确理解这一点。
以下是我对已检查异常的理解：
try{
String userInput = //read in user input
Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
id = 0; //recover the situation by setting the id to 0
}
1.以上是否考虑了检查异常？
2. RuntimeException是未经检查的异常吗？
以下是我对未经检查的异常的理解：
try{
File file = new File("my/file/path");
FileInputStream fis = new FileInputStream(file);
}catch(FileNotFoundException e){
//3. What should I do here?
//Should I "throw new FileNotFoundException("File not found");"?
//Should I log?
//Or should I System.exit(0);?
}
4.现在，上面的代码难道也不是一个经过检查的例外吗？我可以尝试恢复这样的情况吗？我可以吗？ （注意：我的第3个问题在上面的catch内）
try{
String filePath = //read in from user input file path
File file = new File(filePath);
FileInputStream fis = new FileInputStream(file);
}catch(FileNotFoundException e){
//Kindly prompt the user an error message
//Somehow ask the user to re-enter the file path.
}
5.为什么人们会这样做？
public void someMethod throws Exception{
}
他们为什么要让异常泡沫化？是不是更快地处理错误？为什么泡起来？
6.我应该冒泡确切的异常还是使用异常掩盖它？
以下是我的阅读材料
In Java, when should I create a checked exception, and when should it be a runtime exception?
许多人说不应该使用经过检查的异常（即你应该明确地捕获或重新抛出的异常）。例如，它们在C＃中被淘汰，大多数语言都没有它们。所以你总是可以抛出RuntimeException的子类（未经检查的异常）
但是，我认为已检查的异常很有用 - 当您希望强制API的用户考虑如何处理异常情况（如果它是可恢复的）时，会使用它们。只是被检查的异常在Java平台中被过度使用，这让人们讨厌它们。
Here's my extended view on the topic。
至于具体问题：
NumberFormatException是否考虑检查异常？
没有.NumberFormatException未经检查（=是RuntimeException的子类）。为什么？我不知道。 （但应该有一种方法isValidInteger(..)）RuntimeException是一个未经检查的例外吗？
对，就是这样。Exception？
大多数情况下，因为人们懒得考虑要捕捉什么和重新抛出什么。投掷Exception是一种不好的做法，应该避免。唉，没有一条规则可以让您确定何时捕获，何时重新抛出，何时使用已检查以及何时使用未经检查的异常。我同意这会引起很多混乱和很多不好的代码。 Bloch说明了一般原则（你引用了它的一部分）。一般原则是重新抛出可以处理它的图层的异常。
要回答最后一个问题（其他人似乎在上面已经完全回答），“我应该冒泡确切的异常还是使用异常掩盖它？”
我假设你的意思是这样的：
public void myMethod() throws Exception {
// ... something that throws FileNotFoundException ...
}
不，总是声明可能的最精确的异常，或者这样的列表。您声明您的方法能够抛出的例外是您的方法和调用者之间的合同的一部分。抛出"FileNotFoundException"意味着文件名可能无效并且找不到文件;调用者需要智能地处理它。投掷Exception的意思是“嘿，不会发生。交易。”这是一个非常差的API。
在第一篇文章的评论中有一些例子，其中“throws Exception”是一个有效且合理的声明，但对于您将要编写的大多数“normal”代码而言并非如此。
我只想添加一些不使用检查异常的推理。这不是一个完整的答案，但我觉得它确实回答了你的部分问题，并补充了许多其他答案。
每当涉及到检查的异常时，方法签名中的某处就会出现throws CheckedException（CheckedException可能是任何已检查的异常）。签名不会抛出异常，抛出异常是实现的一个方面。接口，方法签名，父类，所有这些都不应该依赖于它们的实现。这里使用已检查的异常（实际上您必须在方法签名中声明throws）将您的更高级别接口与这些接口的实现绑定。
让我举个例子。
让我们拥有一个漂亮干净的界面
public interface IFoo {
public void foo();
}
现在我们可以编写方法foo()的许多实现，就像这些
public class Foo implements IFoo {
@Override
public void foo() {
System.out.println("I don't throw and exception");
}
}
Foo类非常好。现在让我们第一次尝试上课吧
public class Bar implements IFoo {
@Override
public void foo() {
//I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
throw new InterruptedException();
}
}
这个类Bar不会编译。由于InterruptedException是一个经过检查的异常，你必须捕获它（在方法foo（）中使用try-catch）或者声明你正在抛出它（将throws InterruptedException添加到方法签名中）。因为我不想在这里捕获这个异常（我希望它向上传播，所以我可以在其他地方正确处理它），让我们改变签名。
public class Bar implements IFoo {
@Override
public void foo() throws InterruptedException {
throw new InterruptedException();
}
}
这个类Bar也不会编译！ Bar的方法foo（）不会覆盖IFoo的方法foo（），因为它们的签名不同。我可以删除@Override注释，但是我想像IFoo foo;那样对接口IFoo进行编程，然后决定我想要使用哪个实现，比如foo = new Bar();。如果Bar的方法foo（）不会覆盖IFoo的方法foo，那么当我执行foo.foo();时，它不会调用Bar的foo（）实现。
要使Bar的public void foo() throws InterruptedException覆盖IFoo的public void foo()，我必须将throws InterruptedException添加到IFoo的方法签名中。但是，这会导致我的Foo类出现问题，因为它的foo（）方法的签名与IFoo的方法签名不同。此外，如果我将throws InterruptedException添加到Foo的方法foo（）中，我会得到另一个错误，指出Foo的方法foo（）声明它抛出InterruptedException但它从不抛出InterruptedException。
正如你所看到的（如果我在解释这些东西方面做得不错），我抛出一个像InterruptedException这样的已检查异常的事实迫使我将我的接口IFoo绑定到其中一个实现，这反过来会对IFoo造成严重破坏其他实施！
这是检查异常为BAD的一个重要原因。在帽子里。
一种解决方案是捕获已检查的异常，将其包装在未经检查的异常中并抛出未经检查的异常。
subclasses的直接或间接RuntimeException的异常类型都是未经检查的异常。Exception类而非RuntimeException的类都被认为是checked exceptions。checked exception。
如果是这样，编译器会确保在throws子句中捕获或声明异常。throws的checked-exception子句。Exception类被认为足够重要以捕获或声明时，它们被定义为被检查。这是一个简单的规则，可以帮助您决定。它与Java中如何使用接口有关。
拿你的类想象一下为它设计一个接口，使接口描述类的功能，但没有底层实现（作为接口应该）。假装您可能以另一种方式实现该类。
查看接口的方法并考虑它们可能抛出的异常：
如果方法可以抛出异常，则无论底层实现如何（换句话说，它仅描述了该功能），那么它应该是接口中的已检查异常。
如果异常是由底层实现引起的，则它不应该在接口中。因此，它必须是类中未经检查的异常（因为未经检查的异常不需要出现在接口签名中），或者必须将其包装并重新抛出作为接口方法的一部分的已检查异常。
要决定是否应该包装和重新抛出，你应该再次考虑接口的用户是否必须立即处理异常条件，或者异常是如此普遍以至于你无能为力它应该做什么传播堆栈。当表达为您正在定义的新接口的功能时，包装的异常是否有意义，或者它只是一个可能发生在其他方法上的可能错误条件的载体？如果是前者，它可能仍然是一个已检查的异常，否则应该取消选中。
您通常不应该计划“冒泡”异常（捕获和重新抛出）。一个异常应该由调用者处理（在这种情况下它被检查），或者它应该一直到高级处理程序（在这种情况下，如果未选中它是最简单的）。
他们为什么要让异常泡沫化？是不是更快地处理错误？为什么泡起来？
例如，假设您有一些客户端 - 服务器应用程序，并且客户端已经请求了一些无法找到的资源或者在处理用户请求时服务器端可能发生的其他错误，那么这就是它的职责服务器告诉客户端为什么他不能得到他请求的东西，所以为了在服务器端实现这一点，编写代码使用throw关键字而不是吞咽或处理它来抛出异常。如果服务器处理它/吞下它，那么就没有机会向客户暗示发生了什么错误。
注意：为了清楚地描述错误类型的发生，我们可以创建自己的Exception对象并将其抛给客户端。
我认为检查异常对于使用外部库的开发人员来说是一个很好的提醒，在特殊情况下，该库的代码可能会出错。
在这里阅读更多关于已检查与未经检查的例外情况http://learnjava.today/2015/11/checked-vs-unchecked-exceptions/
只是要指出，如果你在代码中抛出一个已检查的异常并且catch是上面的几个级别，你需要在你和catch之间的每个方法的签名中声明异常。因此，封装被破坏，因为throw路径中的所有函数必须知道该异常的细节。
简而言之，上面的模块或模块在运行时应该处理的异常称为检查异常;其他是未经检查的例外，可能是RuntimeException或Error。
在此视频中，它解释了Java中的已检查和未检查的异常： https://www.youtube.com/watch?v=ue2pOqLaArw
所有这些都是经过检查的例外。未经检查的异常是RuntimeException的子类。决定不是如何处理它们，应该是你的代码抛出它们。如果您不希望编译器告诉您尚未处理异常，则使用未经检查（RuntimeException的子类）异常。对于无法恢复的情况，例如内存不足错误等，应保存这些内容。
如果有人关心另一个不喜欢已检查异常的证明，请参阅流行的JSON库的前几段：
“虽然这是一个经过检查的异常，但它很少可以恢复。大多数调用者只需将此异常包装在未经检查的异常中并重新抛出：”
那么为什么世界上有人会让开发人员继续检查异常，如果我们应该“简单地换行”呢？大声笑
http://developer.android.com/reference/org/json/JSONException.html
某些东西是否是“已检查的异常”与您是否捕获它或在catch块中执行的操作无关。它是异常类的属性。除了Exception及其子类之外，任何RuntimeException的子类都是一个经过检查的异常。
Java编译器强制您捕获已检查的异常或在方法签名中声明它们。它本来应该提高程序安全性，但大多数意见似乎是它不值得它创造的设计问题。
他们为什么要让异常泡沫化？不处理错误越快越好？为什么泡起来？
因为这是例外的全部要点。没有这种可能性，您不需要例外。它们使您能够在您选择的级别处理错误，而不是强迫您在最初发生的低级方法中处理它们。
已检查的例外情况：
未经检查的例外情况：
必须检查所有例外异常。
Checked Exception，如果它是RuntimeException。RuntimeException是unchecked exception吗？是Checked Exceptions是subclasses java.lang.Exception的Unchecked Exceptions是subclasses的java.lang.RuntimeException
抛出已检查异常的调用需要包含在try {}块中，或者在方法调用者的上一级中处理。在这种情况下，当前方法必须声明它抛出所述异常，以便调用者可以做出适当的安排来处理异常。
希望这可以帮助。
问：我应该冒泡确切的异常还是使用Exception掩盖它？
答：是的，这是一个非常好的问题和重要的设计考虑因素。 Exception类是一个非常通用的异常类，可用于包装内部低级异常。您最好创建一个自定义异常并将其包装在其中。但是，也是一个重大问题 - 永远不要掩盖潜在的原始根本原因。例如，Don't ever做以下 -
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!.
}
吞噬原始根源会导致实际原因无法恢复，这对于生产支持团队来说是一场噩梦，他们可以访问的是应用程序日志和错误消息。虽然后者是一个更好的设计，但许多人不经常使用它，因为开发人员只是无法将基础消息传递给调用者。所以要做一个坚定的说明：Always pass on the actual exception支持是否包含在任何特定于应用程序的异常中。
在尝试捕捉
RuntimeExceptions
RuntimeExceptions作为一般规则不应该被试图捕获。它们通常表示编程错误，应该保持不变。相反，程序员应该在调用一些可能导致RuntimeException的代码之前检查错误情况。例如：
try {
setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
sendError("Sorry, your userObject was null. Please contact customer care.");
}
这是一个糟糕的编程习惯。相反，应该像以下一样进行空检查 -
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都是RuntimeExceptions，捕捉一个NullPointerException应该替换为优雅的空检查，而我建议明确捕捉NumberFormatException，以避免可能引入容易出错的代码。
1。如果您不确定异常，请检查API：
java.lang.Object extended by java.lang.Throwable extended by java.lang.Exception extended by java.lang.RuntimeException //<-NumberFormatException is a RuntimeException extended by java.lang.IllegalArgumentException extended by java.lang.NumberFormatException
2。是的，以及扩展它的每个例外。
3。没有必要捕获并抛出相同的异常。在这种情况下，您可以显示新的文件对话框。
4。 FileNotFoundException已经是一个已检查的异常。
5。如果期望调用someMethod的方法捕获异常，则可以抛出后者。它只是“传球”。它的一个使用示例是，如果您想将它放在自己的私有方法中，并在公共方法中处理异常。
一个很好的解读是Oracle doc本身：http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html
为什么设计者决定强制一个方法来指定可以在其范围内抛出的所有未捕获的已检查异常？方法抛出的任何异常都是方法的公共编程接口的一部分。那些调用方法的人必须知道方法可以抛出的异常，以便他们可以决定如何处理它们。这些异常与该方法的编程接口一样，也是其参数和返回值的一部分。
下一个问题可能是：“如果记录方法的API非常好，包括它可以抛出的异常，为什么不指定运行时异常呢？”运行时异常表示编程问题导致的问题，因此，无法合理地期望API客户端代码从它们恢复或以任何方式处理它们。这些问题包括算术异常，例如除以零;指针异常，例如尝试通过空引用访问对象;和索引异常，例如尝试通过索引太大或太小来访问数组元素。
在Java Language Specification中还有一些重要的信息：
throws子句中指定的已检查异常类是实现者与方法或构造函数的用户之间的契约的一部分。
底线恕我直言，你可以捕获任何RuntimeException，但你不需要和，实际上不需要实现维护相同的非检查异常抛出，因为那些不是合同的一部分。
1）否，NumberFormatException是未经检查的异常。即使你抓住它（你不是必须的）因为它没有被检查。这是因为它是IllegalArgumentException的子类，它是RuntimeException的子类。
2）RuntimeException是所有未经检查的例外的根源。 RuntimeException的每个子类都未经检查。检查所有其他例外和Throwable除了错误（在Throwable下）。
3/4）您可以提醒用户他们选择了一个不存在的文件并要求新文件。或者只是退出通知用户他们输入的内容无效。
5）投掷和捕捉'Exception'是不好的做法。但更一般地说，您可能会抛出其他异常，以便调用者可以决定如何处理它。例如，如果您编写了一个库来处理读取某些文件输入并且您的方法传递了一个不存在的文件，那么您根本不知道如何处理它。来电者是想再次询问还是退出？所以你将Exception向上链回到调用者。
在许多情况下，由于程序员没有验证输入（在第一个问题中为unchecked Exception），因此会出现NumberFormatException。这就是为什么它可以选择捕获它们，因为有更优雅的方法来避免产生这些异常。
检查 - 容易发生。签入编译时间。
例如.. FileOperations
UnChecked - 由于数据不佳。检查运行时间。
例如..
String s = "abc";
Object o = s;
Integer i = (Integer) o;
Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
at Sample.main(Sample.java:9)
这里的异常是由于数据不良而无法在编译期间确定。
检查的异常在编译时由JVM检查，并且与资源（文件/ db / stream / socket等）相关。检查异常的动机是在编译时如果资源不可用，应用程序应该定义一个替代行为来在catch / finally块中处理它。
未经检查的异常纯粹是程序错误，错误的计算，空数据甚至业务逻辑中的失败都可能导致运行时异常。它绝对可以在代码中处理/捕获未经检查的异常。
我最喜欢的关于unchecked和checked异常之间区别的描述是由Java Tutorial专题文章“Unchecked Exceptions - the Controversy”提供的（很抱歉在这篇文章中得到所有基础 - 但是，嘿，基础知识有时是最好的）：
这是底线指南：如果可以合理地期望客户端从异常中恢复，则将其作为已检查的异常。如果客户端无法执行任何操作以从异常中恢复，请将其设置为未经检查的异常
“抛出什么类型的异常”的核心是语义（在某种程度上），上面的引用提供了很好的指导（因此，我仍然被C＃摆脱检查异常的概念所震惊 - 特别是Liskov认为他们的用处）。
其余部分变得合乎逻辑：编译器希望我明确地响应哪些异常？您希望客户从中恢复的那些。
运行时异常运行时异常称为未经检查的异常。所有其他异常都是经过检查的异常，并且它们不是从java.lang.RuntimeException派生的。
已检查的异常必须在代码中的某处捕获已检查的异常。如果您调用抛出已检查异常的方法但未在某处捕获已检查的异常，则代码将无法编译。这就是为什么它们被称为检查异常：编译器检查以确保它们被处理或声明。
Java API中的许多方法都会抛出已检查的异常，因此您通常会编写异常处理程序来处理由您未编写的方法生成的异常。