如果有人想要另一个不喜欢受控异常的证明，请参阅流行JSON库的前几段:

虽然这是一个受控异常，但它很少是可恢复的。大多数调用方应该简单地将此异常包装在未检查的异常中并重新抛出:"

那么，如果我们应该“简单地包装它”，为什么世界上有人会让开发人员不断检查异常呢?哈哈

http://developer.android.com/reference/org/json/JSONException.html

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

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

上述异常是否被认为是受控异常? 没有 如果异常是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以避免可能引入容易出错的代码。

检查异常:

The exceptions which are checked by the compiler for smooth execution of the program at runtime are called Checked Exception. These occur at compile time. If these are not handled properly, they will give compile time error (Not Exception). All subclasses of Exception class except RuntimeException are Checked Exception. Hypothetical Example - Suppose you are leaving your house for the exam, but if you check whether you took your Hall Ticket at home(compile time) then there won't be any problem at Exam Hall(runtime).

未检查异常:

The exceptions which are not checked by the compiler are called Unchecked Exceptions. These occur at runtime. If these exceptions are not handled properly, they don’t give compile time error. But the program will be terminated prematurely at runtime. All subclasses of RunTimeException and Error are unchecked exceptions. Hypothetical Example - Suppose you are in your exam hall but somehow your school had a fire accident (means at runtime) where you can't do anything at that time but precautions can be made before (compile time).

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

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

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

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