了解 Java 中选中的异常与未选中的异常

许多人说，根本不应该使用选中的异常（即您应该显式捕获或重新抛出的异常）。例如，它们在 C# 中被淘汰了，大多数语言都没有它们。因此，您始终可以抛出 （unchecked exception） 的子类。RuntimeException

但是，我认为选中的异常很有用 - 当您想强制 API 的用户考虑如何处理异常情况（如果可以恢复）时，会使用它们。只是选中的异常在 Java 平台中被过度使用，让人讨厌它们。

这是我对这个话题的扩展看法。

至于具体问题：

1. NumberFormatException 是否被视为已检查的异常？
   不。 未选中 （= 是 的子类）。为什么？我不知道。（但应该有一种方法NumberFormatExceptionRuntimeExceptionisValidInteger(..))

2. RuntimeException 是未经检查的异常吗？
   是的，没错。

3. 我应该在这里做什么？
   这取决于此代码的位置以及您希望发生的情况。如果它在 UI 层中 - 捕获它并显示警告;如果它在服务层 - 根本不要抓住它 - 让它冒泡。只是不要吞下例外。如果发生异常，在大多数情况下，应选择以下选项之一：

• 记录并返回
• rethrow it（声明它由方法抛出）
• 通过在构造函数中传递当前异常来构造一个新异常

4. 现在，上面的代码难道不能也是一个检查异常吗？我可以尝试恢复这样的情况吗？我可以吗？
   本来可以的。但是，没有什么能阻止您捕获未选中的异常。

5. 为什么人们在 throws 子句中添加类 Exception？
   最常见的原因是人们懒得考虑要抓住什么和扔掉什么。投掷是一种不好的做法，应该避免。Exception

唉，没有一个单一的规则可以让你决定何时捕获，何时重新抛出，何时使用选中的异常以及何时使用未选中的异常。我同意这会导致很多混乱和很多糟糕的代码。布洛赫（Bloch）陈述了一般原则（您引用了其中的一部分）。一般原则是将异常重新抛出到可以处理它的层中。

1. 上述情况是否被视为已检查的例外情况？ 不 您正在处理异常这一事实并不能使它成为 .Checked ExceptionRuntimeException

2. 是 ？ 是的RuntimeExceptionunchecked exception

Checked Exceptions是 的subclassesjava.lang.ExceptionUnchecked Exceptionssubclassesjava.lang.RuntimeException

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

希望这会有所帮助。

问：我应该冒泡吗 exception 还是使用 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（） 方法中复制所有字符串到整数的转换代码 - 如果由开发人员实现，则容易出错。因此，最好取消 try-catch。

所以和两者都是，捕获一个应该替换为一个优雅的空检查，而我建议明确地捕获一个以避免可能引入容易出错的代码。NullPointerExceptionNumberFormatExceptionRuntimeExceptionsNullPointerExceptionNumberFormatException

某件事是否是“已检查的异常”与你是否捕获它或你在捕获块中执行的操作无关。它是异常类的属性。除 and 其子类外，任何子类都是选中的异常。ExceptionRuntimeException

Java 编译器强制您捕获已检查的异常或在方法签名中声明它们。它应该提高程序的安全性，但大多数人的意见似乎是，它不值得它造成的设计问题。

为什么他们让异常冒泡 间谍不是越早处理错误 更好？为什么要冒泡？

因为这就是例外的全部意义所在。如果没有这种可能性，您将不需要例外。它们使您能够在您选择的级别上处理错误，而不是强迫您在最初发生错误的低级别方法中处理它们。

所有这些都是选中的异常。未检查的异常是 RuntimeException 的子类。决定的不是如何处理它们，而是你的代码是否应该抛出它们。如果您不希望编译器告诉您您尚未处理异常，则使用未经检查的（RuntimeException 的子类）异常。这些应该保存以备无法恢复的情况，例如内存不足错误等。

1） 否，NumberFormatException 是未经检查的异常。即使你抓住了它（你不需要），因为它是未经检查的。这是因为它是一个子类，其子类是 的子类。IllegalArgumentExceptionRuntimeException

2） 是所有未选中的异常的根源。的每个子类都是未选中的。所有其他异常，并被选中，但错误（位于 下）。RuntimeExceptionRuntimeExceptionThrowableThrowable

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

5）投掷和接球是不好的做法。但更一般地说，您可能会引发其他异常，以便调用方可以决定如何处理它。例如，如果您编写了一个库来处理读取某些文件输入，并且您的方法传递了一个不存在的文件，则您不知道如何处理该问题。来电者是想再问一次还是退出？因此，您将 Exception 沿链返回给调用方。'Exception'

在许多情况下，发生是因为程序员没有验证输入（在第一个问题中）。这就是为什么可以选择捕获它们的原因，因为有更优雅的方法可以避免生成这些异常。unchecked ExceptionNumberFormatException

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 已是已检查的异常。

6 米如果期望调用的方法捕获异常，则可以抛出后者。它只是“传球”。例如，如果您想将其扔到自己的私有方法中，并在公共方法中处理异常。someMethod

一个很好的读物是 Oracle 文档本身：http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

为什么设计人员决定强制使用一种方法来指定可以在其范围内抛出的所有未捕获的已检查异常？方法可以引发的任何异常都是该方法的公共编程接口的一部分。调用方法的人必须知道方法可能引发的异常，以便他们可以决定如何处理这些异常。这些异常与其参数和返回值一样，都是该方法编程接口的一部分。

下一个问题可能是：“如果记录一个方法的 API（包括它可能引发的异常）非常好，为什么不也指定运行时异常呢？运行时异常表示由编程问题引起的问题，因此，不能合理地期望 API 客户端代码从中恢复或以任何方式处理它们。此类问题包括算术例外，例如除以零;指针异常，例如尝试通过空引用访问对象;以及索引异常，例如尝试通过过大或过小的索引访问数组元素。

Java 语言规范中还有一个重要的信息：

throws 子句中命名的已检查异常类是方法或构造函数的实现者和用户之间协定的一部分。

恕我直言，底线是您可以捕获任何 ，但您不需要这样做，事实上，实现不需要维护抛出的相同的未经检查的异常，因为这些异常不是合同的一部分。RuntimeException

为了回答最后一个问题（上面的其他问题似乎已经完全回答了），“我应该冒出确切的异常还是使用 Exception 来掩盖它？

我假设你的意思是这样的：

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

不，始终声明最精确的例外情况，或列出此类情况。将方法声明为能够引发的异常是方法与调用方之间协定的一部分。抛出意味着文件名可能无效，并且找不到文件;呼叫者需要明智地处理这个问题。投掷的意思是“嘿，嘘，发生了。交易。这是一个非常可怜的."FileNotFoundException"ExceptionAPI

在第一篇文章的评论中，有一些例子表明“throws”是一个有效且合理的声明，但对于你将要编写的大多数“”代码来说，情况并非如此。Exceptionnormal

如果有人关心另一个不喜欢检查异常的证据，请参阅流行的 JSON 库的前几段：

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

那么，如果我们应该“简单地包装它”，为什么有人会让开发人员继续检查异常呢？哈哈

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

他们为什么让例外冒泡？越早处理错误不是更好吗？为什么要冒泡？

例如，假设您有一些客户端-服务器应用程序，并且客户端对某些无法找到的资源发出了请求，或者对于其他错误，在处理用户请求时，服务器端可能发生了一些错误，那么服务器有责任告诉客户端为什么他无法获得他请求的东西，因此，为了在服务器端实现这一点，编写代码以使用 throw 关键字抛出异常，而不是吞咽或处理它。如果服务器处理它/吞下它，那么就没有机会向客户端暗示发生了什么错误。

注意：为了清楚地描述发生的错误类型，我们可以创建自己的 Exception 对象并将其抛给客户端。

• Java 区分了两类异常（选中和未选中）。
• Java 对已检查的异常强制执行 catch 或声明要求。
• 异常的类型决定了异常是选中还是未选中。
• 所有直接或间接的类异常类型都是未选中的异常。subclassesRuntimeException
• 所有继承自 class 但不是 的类都被视为 。ExceptionRuntimeExceptionchecked exceptions
• 继承自 Error 类的类被视为未选中。
• 编译器检查每个方法调用和减速，以确定 方法抛出 。checked exception
  • 如果是这样，编译器将确保捕获异常或在 throws 子句中声明异常。
• 为了满足 catch-or-declare 要求的 declare 部分，生成的方法 例外必须提供包含 .throwschecked-exception
• 异常类被定义为在被认为足够重要以捕获或声明时进行检查。

这里有一个简单的规则，可以帮助您做出决定。它与接口在 Java 中的使用方式有关。

以你的类为例，想象为它设计一个接口，使该接口描述类的功能，但不描述底层实现（接口应该如此）。假装你可能以另一种方式实现该类。

查看接口的方法，并考虑它们可能引发的异常：

如果一个方法可以引发一个异常，而不管底层实现如何（换句话说，它只描述功能），那么它可能应该是接口中的一个检查异常。

如果异常是由基础实现引起的，则不应在接口中。因此，它必须是类中未选中的异常（因为未选中的异常不需要出现在接口签名中），或者必须将其包装并作为作为接口方法一部分的已检查异常重新引发。

要决定是否应该换行并重新抛出，您应该再次考虑接口的用户是否必须立即处理异常条件，或者异常非常普遍，以至于您对此无能为力，它应该向上传播堆栈。当表示为正在定义的新接口的功能时，包装的异常是否有意义，或者它只是其他方法也可能发生的可能错误条件的载体？如果是前者，它可能仍是选中的异常，否则应取消选中。

您通常不应该计划“冒泡”异常（捕获和重新抛出）。异常应由调用方处理（在这种情况下，它被检查），或者它应该一直到高级处理程序（在这种情况下，如果未选中它，则最容易）。

选中的异常由 JVM 及其与资源（files/db/stream/socket 等）相关的资源在编译时检查。检查异常的动机是，在编译时，如果资源不可用，应用程序应定义另一种行为来在 catch/finally 块中处理此问题。

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

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

选中 - 容易发生。已在编译时选中。

例如..文件操作

未选中 - 由于数据错误。已签入运行时。

例如..

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)

这里的异常是由于数据错误造成的，在编译时无法确定。

关于未检查异常和已检查异常之间差异，我最喜欢的描述是由 Java 教程跟踪文章“未经检查的异常 - 争议”提供的（很抱歉在这篇文章中了解所有基本内容 - 但是，嘿，基础知识有时是最好的）：

这是底线准则：如果客户可以合理地 预期从异常中恢复，使其成为已检查的异常。如果 客户端无法执行任何操作来从异常中恢复，请将其设置为 未选中的异常

“抛出什么类型的异常”的核心是语义（在某种程度上），上面的引文提供了很好的指导（因此，我仍然对 C# 摆脱了检查异常的概念感到震惊 - 特别是当 Liskov 论证它们的有用性时）。

剩下的就变得合乎逻辑了：编译器希望我明确地响应哪些异常？您希望客户端从中恢复的那些。

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

我只想添加一些根本不使用检查异常的理由。这不是一个完整的答案，但我觉得它确实回答了你的部分问题，并补充了许多其他答案。

每当涉及已检查的异常时，方法签名中都会有一个（可以是任何已检查的异常）。签名不会抛出 Exception，抛出 Exception 是实现的一个方面。接口、方法签名、父类，所有这些东西都不应该依赖于它们的实现。此处使用选中的异常（实际上是您必须在方法签名中声明的事实）是将更高级别的接口与这些接口的实现绑定在一起。throws CheckedExceptionCheckedExceptionthrows

让我举个例子。

让我们有一个像这样漂亮而干净的界面

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");
    }
}

Class Foo完全没问题。现在让我们第一次尝试一下 Bar 类

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 like 进行编程，然后决定要使用哪个实现，例如 .如果 Bar 的方法 foo（） 没有覆盖 IFoo 的方法 foo，当我这样做时，它不会调用 Bar 的 foo（） 实现。IFoo foo;foo = new Bar();foo.foo();

要使 Bar 覆盖 IFoo 的，我必须添加到 IFoo 的方法签名中。但是，这将导致我的 Foo 类出现问题，因为它是 foo（） 方法的签名与 IFoo 的方法签名不同。此外，如果我添加到 Foo 的方法 foo（），我会得到另一个错误，指出 Foo 的方法 foo（） 声明它抛出一个 InterruptedException，但它从不抛出 InterruptedException。public void foo() throws InterruptedExceptionpublic void foo()throws InterruptedExceptionthrows InterruptedException

正如你所看到的（如果我在解释这些东西方面做得不错），我抛出一个像 InterruptedException 这样的选中异常这一事实迫使我将我的接口 IFoo 绑定到它的一个实现，这反过来又对 IFoo 的其他实现造成了严重破坏！

这是检查异常是坏的一个重要原因。大写。

一种解决方案是捕获已检查的异常，将其包装在未检查的异常中，然后引发未检查的异常。

需要指出的是，如果你在代码中抛出一个选中的异常，并且捕获在上面几个级别，你需要在你和捕获之间的每个方法的签名中声明异常。因此，封装被破坏了，因为抛出路径中的所有函数都必须知道该异常的详细信息。

运行时异常： 运行时异常称为未经检查的异常。所有其他例外情况 是选中的异常，它们不是派生自 java.lang.RuntimeException。

已检查的异常： 选中的异常必须在代码中的某个位置捕获。如果调用 引发已检查异常但未捕获已检查异常的方法 在某个地方，您的代码将无法编译。这就是为什么它们被称为检查的原因 异常 ：编译器检查以确保它们被处理或声明。

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

已检查的异常：

• 编译器为在运行时顺利执行程序而检查的异常称为“检查异常”。

• 这些发生在编译时。

• 如果处理不当，它们将给出编译时错误（非异常）。

• 除 RuntimeException 之外，Exception 类的所有子类都是 Checked Exception。

  假设示例 - 假设你要离开家去考试，但如果你检查你是否在家（编译时）拿了你的大厅门票，那么在考试大厅（运行时）不会有任何问题。

未选中的异常：

• 编译器未检查的异常称为未检查的异常。

• 这些发生在运行时。

• 如果这些异常处理不当，它们不会产生编译时错误。但是该程序将在运行时过早终止。

• RunTimeException 和 Error 的所有子类都是未经检查的异常。

  假设示例 - 假设您在考场，但不知何故，您的学校发生了火灾事故（意味着在运行时），当时您无法做任何事情，但可以在之前（编译时）采取预防措施。

必须检查所有异常。

1. 未经检查的异常是不受限制的 gotos。不受限制的 gotos 被认为是一件坏事。

2. 未经检查的异常会破坏封装。为了正确处理它们，必须知道投掷器和捕获器之间的调用树中的所有函数，以避免错误。

3. 异常是引发它们的函数中的错误，而不是处理它们的函数中的错误。异常的目的是通过将是否为错误的决定推迟到另一个上下文来给程序第二次机会。只有在另一种情况下才能做出正确的决定。

简而言之，上面的一个或多个模块应该在运行时处理的异常称为已检查异常;其他是未经检查的异常，它们是 或 .RuntimeExceptionError

在此视频中，它解释了 Java 中选中和未选中的异常：
https://www.youtube.com/watch?v=ue2pOqLaArw