Exception和Error有什么区别？

一、引言

有程序的地方，就会有异常。如何正确处理异常是保证程序稳定运行的关键，对于开发高质量的软件具有重要意义。Java异常处理机制提供了灵活、强大且易用的异常处理能力，为Java语言在构建健壮、可维护的程序方面提供了坚实基础。

二、面试

题目：请对比 Exception 和 Error，另外，运行时异常与一般异常有什么区别？

典型回答

在Java编程中，Exception和Error都是继承自java.lang.Throwable类的子类，它们构成了Java异常处理体系的基础。

• Exception：在Java中，Exception是程序运行时遇到的可预见的问题，这些通常是由于程序本身的逻辑错误或外部资源的不可用等因素引起的。Exception又分为两种：
  • Checked Exceptions（受检异常）：在编译时期就需要处理的异常，如果不捕获或声明抛出，代码将无法通过编译。例如，IOException、SQLException等，它们通常表示可以通过合理编程逻辑预防或恢复的情况。
  • Unchecked Exceptions（运行时异常）：继承自RuntimeException的异常，如NullPointerException、ArrayIndexOutOfBoundsException等，这些异常通常是因为编程时的逻辑错误或者运行时环境的不一致造成的，编译器不会强制要求处理，但在运行时若不处理则会导致程序突然中断。
• Error：Error类通常代表了Java运行时环境中的严重问题，它们通常是不可恢复的错误，如VirtualMachineError（包括OutOfMemoryError、StackOverflowError等），或者是系统资源不足、系统错误等。Error的发生通常暗示着JVM或操作系统层面的问题，应用程序一般无法处理这些错误，即使捕获也往往无法正常恢复程序运行。

运行时异常（Unchecked Exception）与其他异常（Checked Exception）的区别

• 运行时异常：如前所述，这些异常是继承自RuntimeException的，编译器不强制要求处理，但发生时往往意味着代码中有基本的逻辑错误或者不合法操作，比如空指针访问、数组越界、类型转换错误等。
• 一般异常（Checked Exception）：这里的一般异常主要是指编译器强制要求处理的异常，它们不继承自RuntimeException。程序员在编码时必须显式捕获或在方法签名中声明抛出，否则代码无法通过编译。这类异常往往表示的是程序运行时可能会遇到的可以预见的问题，如文件不存在、网络连接失败等，这些问题虽不至于导致整个程序崩溃，但需要明确处理以确保程序逻辑的完整性和健壮性。

考点分析

首先，要深入理解Throwable、Exception、Error的设计理念和分类。这包括掌握那些在实际应用中最为常见的子类，并熟悉如何根据实际需求自定义异常。

在面试过程中，面试官往往会针对这些细节进行进一步的询问。例如，他们可能会问到你对哪些特定的Error、Exception或RuntimeException有所了解？为此，我精心绘制了一个简洁的类图，并列举了一些典型的例子，供你参考。通过熟悉这些例子，你至少能够对Throwable、Exception、Error的基本分类和常用子类有一个清晰的认识。
在这些子类型中，有些特别重要，需要重点理解。比如，NoClassDefFoundError和ClassNotFoundException这两个异常的区别就是面试中经常出现的经典问题。理解它们之间的不同点，将帮助你更好地掌握Java异常处理机制，为你的面试增添更多信心。

深入理解Java语言中操作Throwable的相关要素和实践是至关重要的。你必须熟练掌握基本的语法结构，例如try-catch-finally块，以及throw和throws关键字等。与此同时，你还需要懂得如何妥善处理各种典型场景中的异常。

编写异常处理代码时，可能会遇到一些繁琐的工作，比如编写大量重复的捕获代码或在finally块中进行资源回收。然而，随着Java语言的不断发展，一些更为便捷的特性也应运而生。比如try-with-resources和multiple catch等机制，它们能够简化异常处理的流程。以try-with-resources为例，它在编译时期会自动生成相应的处理逻辑，能够自动关闭那些实现了AutoCloseable或Closeable接口的对象，极大地减轻了开发者的负担。
因此，要想在Java中高效地处理异常，你不仅要掌握基本的语法和技巧，还需要善于利用这些高级特性来简化你的代码，提高程序的健壮性和可维护性。

三、Exception与Error的区别

Exception和Error都是Throwable的子类

Exception和Error都是Throwable类的子类。它们都是Java异常处理机制的基本组成类型，用于描述程序运行过程中可能出现的异常情况。

Exception是可预料的异常情况，Error是难以恢复的严重错误

Exception 和 Error 类别在 Java 平台中彰显了设计者对各类异常状况的精细区分。
Exception 类型是用来表示程序执行过程中预期可能出现的意外情况，这些异常通常是由于外部条件不满足或程序逻辑中预见到的问题所引发的。例如，文件未找到(FileNotFoundException)、网络连接失败(SocketException)等。这类异常在编码时应当预见并适当地通过 try-catch 结构来捕获和处理，以便让程序能够适应异常条件，恢复正常运作或优雅地终止执行。
而 Error 类型则代表了一种更为严重的、通常在正常程序运行环境下难以预见也难以从其中恢复的情况。它们常常与 Java 虚拟机(JVM)内部错误、系统资源耗尽或其他底层问题相关联，如内存溢出错误(OutOfMemoryError)、系统级故障等。由于这类错误通常指示了程序已进入一种无法继续执行的状态，因此，尽管在技术上也可以捕获 Error，但实践中并不建议这样做，因为它们往往代表着更深层次的问题，已经超出了应用程序能够有效恢复控制的范围。

Exception包括可检查异常和运行时异常

Exception 类在 Java 中进一步细分为两类：可检查（checked）异常和不检查（unchecked）异常。前者在编程时有严格的编译时要求，即开发人员必须在源代码中显式地对这类异常进行捕获处理，或者在方法签名中通过 throws 关键字声明将其向上抛给调用者。编译器会对此类异常进行静态检查，确保在执行前就已经有了相应的处理策略。
而不可检查的异常，实际上指的是那些继承自 RuntimeException 的异常，它们属于运行时异常范畴。像 NullPointerException、ArrayIndexOutOfBoundsException 等，往往是由于编程时的逻辑错误所引起的，理论上可通过改进代码逻辑来预防。相较于可检查异常，Java 编译器并不会强制要求对这类运行时异常进行捕获处理，然而在实际开发中，尽管不是编译时义务，良好的编程习惯仍然建议对这类异常进行合理的错误检测和处理，以提高程序健壮性和用户体验。

四、异常处理实践建议

尽量避免捕获通用异常

在编程实践中，应尽量避免捕获过于笼统的 Exception 异常类型，转而优先选择捕获具有明确含义的特定异常，例如在涉及线程休眠操作时，直接捕获 InterruptedException。原因在于，编写易于理解和维护的代码对于团队协作至关重要，而宽泛的 Exception 异常处理往往会掩盖具体的错误信息和异常意图，使得其他开发者难以快速定位问题所在。
此外，恰当的异常处理还应遵循“只处理预期的异常”原则。若无特殊需求，不应随意捕获 RuntimeException 或其子类，因为这些异常通常反映了程序中的逻辑错误，应当允许它们自然地向上冒泡，触发更高层级的异常处理机制，从而有助于迅速暴露问题。
同时，对于 Throwable 或 Error 类型的异常，如果没有经过周详考虑和充分准备，不建议轻易捕获。此类异常通常标志着严重的系统级错误，如 OutOfMemoryError，它们的处理通常超出了常规业务逻辑范围，且不当的处理方式可能会导致程序陷入不稳定状态或掩盖真正的问题所在。正确的做法是在必要时记录相关信息并尽可能让程序优雅地终止，而非盲目尝试恢复执行。

不要生吞异常，应记录或抛出

在处理异常时，一个关键的注意事项是要避免“生吞”异常，也就是在 catch 块中捕获异常后不做任何处理，或者只是简单地打印堆栈跟踪然后继续执行。这种做法可能导致程序行为变得难以预测和调试，特别是当潜在的问题没有得到及时发现和解决时，很可能在后续代码中引发更严重的问题。
在示例代码中：

try {
   // 业务代码
} catch (IOException e) {
    e.printStackTrace();
}

这段代码在开发阶段用于快速测试和调试或许尚可接受，但在生产环境中却不被推荐。原因在于 e.printStackTrace() 将异常信息输出到了标准错误流(STDERR)，这对于复杂的生产环境来说并不是一个理想的选择。首先，标准错误流的输出位置可能并不固定，尤其是在服务器或分布式环境中，输出内容可能被淹没在众多其他系统输出之中，不利于问题追踪；其次，这种方式并未将异常信息整合到统一的日志管理系统中，无法实现高效检索和分析。
因此，在产品代码中，更好的做法是将异常信息完整地记录到日志系统中，例如使用 Logger 工具，不仅能详细记录异常堆栈轨迹，还可以包含上下文信息，方便定位问题根源：

try {
   // 业务代码
} catch (IOException e) {
    logger.error("An IOException occurred while processing business logic", e);
}

这样一来，无论是本地部署还是分布式系统中，一旦出现异常，都可以通过日志系统迅速准确地定位到问题所在，极大地提高了系统的可维护性和稳定性。

使用throw early, catch late原则

Throw early 指的是在问题最早能被检测到的地方立即抛出异常。这意味着当一个方法接收到非法参数、资源未初始化或某种状态不允许继续执行时，应尽快抛出异常，而不是等到问题在后续执行流程中变得更隐蔽时才抛出。
示例：

public void addUser(String username, String password) {
    // Throw early: 如果用户名为空，则立即抛出异常
    if (username == null || username.isEmpty()) {
        throw new IllegalArgumentException("Username cannot be null or empty");
    }
    
    // 其他业务逻辑，如密码验证、数据库操作等
    // ...
}

Catch late 则强调在尽可能靠近业务逻辑处理中心，或者在能够适当处理异常的地方捕获异常。避免过早地捕获并可能误处理异常，应在高层次模块中捕获并处理那些确实需要处理的异常，同时确保异常信息能够反映出问题的本质。
示例：

public void processUserData(UserData userData) {
    try {
        validateUserData(userData); // 这个函数可能会抛出异常，但我们在这儿不捕获
        addUser(userData.getUsername(), userData.getPassword());
        saveUserDataToDatabase(userData);
    } catch (IllegalArgumentException | UserDataValidationException e) {
        // Catch late: 在顶层业务逻辑中捕获并处理异常
        log.error("Invalid user data provided: {}", e.getMessage());
        sendErrorMessageToClient(e.getMessage());
    } catch (DatabaseOperationException e) {
        // 对数据库操作异常进行处理
        log.error("Error saving user data to database: {}", e.getMessage());
        rollbackTransaction();
        notifyAdminAboutError(e);
    }
}

private void validateUserData(UserData userData) throws UserDataValidationException {
    // 验证用户数据并在这儿尽早抛出异常
    // ...
    if (userData.getUsername() == null || userData.getUsername().isEmpty()) {
        throw new UserDataValidationException("Username is missing");
    }
    // 更多验证逻辑...
}

在这个示例中，validateUserData 方法遵循了“Throw early”原则，一旦发现用户数据无效，就立即抛出异常。而 processUserData 方法则遵循了“Catch late”原则，它在高层业务逻辑中捕获并处理来自低层方法抛出的异常。

自定义异常时注意信息安全

在自定义异常时，确实需要综合考虑多种因素以确保异常设计的合理性和安全性：

1. 是否为 Checked Exception：如果你设计的异常是一种预期可以通过程序员采取合理行动来恢复的异常情况，那么它可能适合被定义为 Checked Exception（编译时异常）。例如，如果你的API在某种条件下需要用户手动干预才能继续执行，此时自定义一个 Checked Exception 可以强制调用者处理这种情况。反之，如果异常表示的是编程错误或无法预见的运行时异常，通常更适合定义为 Unchecked Exception（运行时异常），如继承自 RuntimeException 的子类。
2. 异常信息的设计：

• 诊断信息充足：自定义异常应包含足够的描述信息，帮助开发者或运维人员快速定位问题所在，但不必包含过于详尽的实施细节，确保异常信息能够传达出问题的核心原因即可。
• 信息安全：在设计异常信息时，务必避免泄漏敏感信息，如用户数据、服务器地址、密钥等。正如你提到的 java.net.ConnectException，它仅提供了一般性的错误描述，而不泄露具体的网络连接细节。在构造异常消息时，可以使用模糊化处理或不直接输出敏感内容，特别是在公开日志中，应严格遵守安全规范，防止敏感信息泄露。

举例说明自定义一个安全的 Checked Exception：

public class CustomResourceAccessException extends Exception implements Serializable {

    private static final long serialVersionUID = 1L;

    public CustomResourceAccessException(String message) {
        super(sanitizeMessage(message));
    }

    // 示例方法，用于清理可能包含敏感信息的消息
    private static String sanitizeMessage(String rawMessage) {
        // 在此处添加逻辑来清除敏感信息，比如替换IP地址、端口号等
        // 返回一个安全的错误消息
        return "Access to resource failed due to: " + maskedMessage;
    }
}

总之，自定义异常不仅要关注功能需求，还要兼顾安全性，确保异常处理既能满足诊断需求，又能保障系统的整体安全。

有关Checked Exception的争议

Java 中的 Checked Exception（编译时异常）自其诞生以来便引起了广泛的讨论和争议。批评者主要提出以下几个观点：

1. 假定可恢复性：Checked Exception 设计的基本理念是鼓励开发者处理这些异常，并尝试恢复程序的正常执行。然而，在许多实际场景中，程序员往往并不能有效地处理这些异常并恢复程序的正常状态，而是仅仅是为了满足编译要求而进行捕获并抛出。
2. 与 Functional 编程不兼容：Checked Exception 在 Java 8 引入 Lambda 表达式和 Stream API 后显得尤为尴尬。Functional 接口通常不能声明 checked 异常，这导致在使用 Lambda 表达式时，如果方法签名中含有 checked 异常，就必须额外包装或处理异常，降低了代码的简洁性和易读性。
3. 行业实践的变化：越来越多的现代框架和库（如Spring、Hibernate等）倾向于使用 unchecked 异常（继承自 RuntimeException）代替 checked 异常，认为这样可以简化代码，减少不必要的异常处理噪声。同时，一些新兴的 JVM 语言（如Scala）也摒弃了 checked exception 的设计。
   尽管如此，Checked Exception 仍有其支持者，他们认为对于诸如 I/O、网络通信等操作产生的异常，确实有可能进行有效的错误恢复，通过强制程序员处理这些异常，有利于增强程序的健壮性和可靠性。
   总而言之，Checked Exception 是否是设计错误仍存在较大争议，不同开发者和团队可以根据自身的项目需求、团队规范以及个人编程风格权衡利弊，选择最适合的异常处理策略。Bruce Eckel 在其演讲中也深入探讨了异常处理的发展趋势及其在现代编程实践中的地位变化。

五、异常处理的性能考虑

try-catch性能开销

使用 try-catch 代码块会带来一定的性能开销，因为它涉及到 JVM 层面的异常处理机制，包括生成和遍历异常表、保存和恢复堆栈信息等操作。尤其当 try 块中的代码频繁执行时，这些开销可能会累积起来，影响程序的整体性能。
因此，最佳实践是仅针对可能会抛出异常且需要处理的代码部分使用 try-catch，而不是将大段的代码包裹在 try 块中。只有在预计可能出现异常的情况下，才应该捕获异常，并进行适当的错误处理或恢复操作。
另外，虽然异常机制能够用来改变代码流程，但从性能和代码清晰度的角度考虑，它并不适合作为常规的流程控制工具。相比于传统的条件语句（如 if/else、switch），异常处理的效率更低，且不易于阅读和理解。在设计程序时，应尽量将异常处理用于处理意料之外的错误情况，而不是用作替代正常的程序逻辑控制。

异常实例化开销

在 Java 中，每当一个异常被抛出并被捕获时，JVM 都需要执行一系列操作，其中包括：

1. 栈轨迹（StackTrace）收集：创建一个新的异常实例时，系统会自动记录当前线程的调用栈信息，这个过程涉及到对内存的分配和数据的填充，特别是对于那些包含大量栈帧信息的复杂调用链路，其开销不可忽视。
2. 堆栈展开（Stack Unwinding）：当异常发生时，JVM 必须从当前方法开始回溯调用栈，释放每个方法调用帧中的局部变量，直至找到合适的 catch 块来处理该异常，这个过程也会消耗一定的时间和资源。
3. 垃圾回收（Garbage Collection）：异常对象本身以及可能与之关联的栈轨迹信息都将成为垃圾收集器管理的对象，尤其是在高并发场景下，频繁的异常生成可能导致更频繁的垃圾回收，间接增加系统的压力。

因此，在设计和编码时，开发者应当遵循“预防优于治疗”的原则，尽量避免不必要的异常产生，只在真正可能发生错误处理或状态异常的地方合理使用 try-catch 机制。同时，也应尽量减少异常的传播深度，比如通过预检查条件、使用智能预测的编程方式等手段来优化代码，降低由于异常处理带来的性能损失。

异常性能调优思路

确实如此，在某些极度关注性能的应用场景中，例如低级别的系统库或嵌入式系统，有时可能会选择实现一种特殊的异常类，它们不存储完整的堆栈轨迹以减少开销。这样的异常通常被称为“轻量级异常”或“无栈异常”。
然而，如您所言，这种方式的确存在明显的折衷之处。它依赖于开发人员能够准确判断何时可以安全地忽略堆栈跟踪信息，而这在实际情况中往往难以预见。特别是在复杂的软件架构中，如微服务或者分布式系统，一旦出现问题，缺乏详细的堆栈信息会让故障排查变得极其困难，甚至不可能。
为了平衡性能与调试能力，一些高性能系统可能采用一种混合策略：

• 对于预期的、易于处理且不会导致严重问题的异常，可以使用无栈或简化的异常；
• 对于非预期的或关键路径上的异常，仍保留完整的堆栈信息以备后期分析。
  另外，现代 JVM 提供了一些机制来优化异常处理的成本，比如在生产环境中可以通过 -XX:-OmitStackTraceInFastThrow 等 JVM 参数调整特定情况下的异常行为，但这同样要求开发者充分理解应用场景，并谨慎决定是否牺牲调试信息换取性能提升。总的来说，除非有充足的理由和严谨的设计，一般不推荐随意省略异常堆栈信息的收集。

七、其它

公众号

若有收获，就点个赞吧