约书亚 · 布洛赫（Joshua Bloch）在《有效的 Java 》中说
将检查的异常用于可恢复的条件，将运行时异常用于编程错误（第二版中的项目 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. 现在，上面的代码难道不是一个检查过的异常吗？我可以尝试恢复这种情况吗？我可以吗？ （注：我的第三个问题是，里面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. 我应该冒充确切的异常还是使用 Exception 屏蔽它？
以下是我的读物
许多人说根本不应该使用检查的异常（即应明确捕获或重新抛出的异常）。例如，它们在 C＃中已被淘汰，并且大多数语言都没有它们。因此，您始终可以抛出RuntimeException的子类（未经检查的异常）
但是，我认为检查异常非常有用 - 当您要强制 API 用户考虑如何处理特殊情况（如果可恢复）时，可以使用它们。只是在 Java 平台中过度使用了已检查的异常，这使人们讨厌它们。
至于特定的问题：
NumberFormatException是否考虑检查异常？
否。 NumberFormatException （= 是RuntimeException子类）。为什么？我不知道。 （但应该有一个方法isValidInteger(..) ）
RuntimeException是未经检查的异常吗？
对，就是这样。
我在这里该怎么办？
这取决于该代码在哪里以及您想要发生什么。如果它在 UI 层中 - 捕获它并显示警告；如果它在服务层中 - 根本不要抓住它 - 让它冒泡。只是不要吞下异常。如果在大多数情况下发生异常，则应选择以下一种：
现在，上面的代码难道不是一个检查过的异常吗？我可以尝试恢复这种情况吗？我可以吗？
可能是这样。但是也没有什么可以阻止您捕获未经检查的异常
人们为什么要在 throws 子句中Exception
大多数情况下，是因为人们懒于考虑要捕获什么和重新抛出什么。抛出Exception是一种不好的做法，应该避免。
las，没有一个单一的规则可以让您确定何时捕获，何时重新抛出，何时使用已检查的异常以及何时使用未检查的异常。我同意这会引起很多混乱和很多错误的代码。 Bloch 陈述了一般原则（您引用了其中的一部分）。通常的原则是将异常抛出到可以处理它的层。
某项是否为 “受检查的异常” 与您是否捕获它或在 catch 块中执行的操作无关。这是异常类的属性。除了RuntimeException及其子类之外，任何其他属于Exception的子类都是已检查的异常。
Java 编译器迫使您要么捕获检查的异常，要么在方法签名中声明它们。本来可以提高程序安全性，但是大多数人似乎认为这样做不值得产生设计上的问题。
为什么他们让异常冒出来？处理错误越早越好吗？为什么冒泡？
因为这是例外的全部要点。没有这种可能性，您将不需要例外。它们使您能够在选择的级别上处理错误，而不是强迫您使用错误最初发生的低级方法进行处理。
以上是否被视为经过检查的例外？ No 如果您处理的是RuntimeException异常，则不会使它成为Checked Exception 。
RuntimeException是unchecked exception吗？是的
Checked Exceptions是java.lang.Exception subclasses 。 Unchecked Exceptions是java.lang.RuntimeException subclasses 。
引发检查异常的调用需要包含在 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
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（）方法内复制所有字符串到整数的转换代码 - 如果由开发人员实现，则容易出错。因此，最好不要尝试捕获。
因此NullPointerException和NumberFormatException都是RuntimeExceptions ，捕获NullPointerException应该替换为优美的空检查，同时我建议NumberFormatException以避免可能引入的容易出错的代码。