Java核心技术Exception和Error的区别

Posted 2021-09-11 sysu_lluozh

Java语言在设计之初就提供相对完善的异常处理机制，这种机制大大降低了编写和维护可靠程序的门槛，如今异常处理机制已成为编程语言的标配

有两个问题：

1. 对比Exception和Error
2. 运行时异常与一般异常有什么区别？

一、典型回答

1.1 Exception和Error都继承Throwable类

在Java中只有Throwable类型的实例才可以被抛出throw或者捕获catch，它是异常处理机制的基本组成类型

1.2 不同异常情况的分类

Exception和Error体现Java平台设计者对不同异常情况的分类

• Exception

程序正常运行中可以预料的意外情况，可能并且应该被捕获，进行相应处理

• Error

指在正常情况下不大可能出现的情况，绝大部分的Error都会导致程序(比如JVM自身)处于非正常的、不可恢复状态。既然是非正常情况，所以不便于也不需要捕获，常见的比如OutOfMemoryError之类，都是Error的子类

1.3 检查异常和不检查异常

Exception分为可检查(checked)异常和不检查(unchecked)异常

• 可检查异常

可检查异常在源代码里必须显式地进行捕获处理，这是编译期检查的一部分

• 不检查异常

不检查异常就是所谓的运行时异常，类似NullPointerException、ArrayIndexOutOfBoundsException之类，通常是可以编码避免的逻辑错误，具体根据需要来判断是否需要捕获，并不会在编译期强制要求

检查异常：
没有继承RuntimeException的Exception属于检查异常，这类问题在编译期就可以确定的问题，如FileNotFoundException、IOException
编译器对检查异常的处理要求：1.try…catch捕获 2. 不断向上抛出，交由jvm来处理
非检查异常：
继承RuntimeException的Exception，非检查异常也叫运行时异常，这类问题大部分属于逻辑问题，如数组越界、空指针异常，只有运行时才能知道的问题，异常在编译时不会检查
编译器对非检查异常的处理要求：1.try…catch捕获 2. 不断向上抛出 3.不处理

二、考点分析

分析Exception和Error的区别，是从概念角度考察Java处理机制

在日常编程中，如何处理好异常是比较考验功底的，需要掌握两个方面：

2.1 理解Throwable、Exception、Error的设计和分类

理解Throwable、Exception、Error的设计和分类，需要掌握应用最为广泛的子类，以及如何自定义异常等

其中更细节的一些问题，比如有哪些Error、Exception或者RuntimeException？

下面画了一个简单的类图并列出来典型例子：

其中有些子类型需要重点理解，比如NoClassDefFoundError和ClassNotFoundException有什么区别？

• NoClassDefFoundError是指一个class在编译时存在，在运行时找不到class文件
• ClassNotFoundException是使用类似Class.foName()等方法时的checked exception

2.2 理解操作Throwable的元素和实践

2.2.1 基本语法

掌握最基本的语法是必须的，如try-catch-finally块，throw、throws关键字等。与此同时，也要懂得如何处理典型场景

throw和throws使用和区别
throw：

1. throw是语句抛出一个异常，一般是在代码块的内部，当程序出现某种逻辑错误时由程序员主动抛出某种特定类型的异常
2. 定义在方法体内
3. 创建的是一个异常对象
4. 确定了发生哪种异常才可以使用

throws：

1. 在方法参数列表后，throws后可以跟着多个异常名，表示抛出的异常用逗号隔开
2. 表示向调用该类的位置抛出异常，不在该类解决
3. 可能发生哪种异常throws用在方法声明后面，跟的是异常类名

其他异同：

1. throw用在方法体内，跟的是异常对象名，且只能抛出一个异常对象名，throws可以跟多个异常类名，用逗号隔开
2. throw表示抛出异常由方法体内的语句处理，throws表示抛出异常由该方法的调用者来处理
3. throw表示抛出了异常，执行throw则一定抛出了某种异常，throws表示出现异常的一种可能性，并不一定会发生这些异常，

2.2.2 便利特性

异常处理代码比较繁琐，比如需要写很多千篇一律的捕获代码，或者在finally里面做一些资源回收工作
随着Java语言的发展，引入了一些更加便利的特性：

1. 比如try-with-resources和multiple catch，在编译时期自动生成相应的处理逻辑
2. 比如自动按照约定俗成close那些扩展了AutoCloseable或者Closeable的对象

便利特性的使用：

• try-with-resources

FileInputStream fis = new FileInputStream(file);
try {
  // do something
} finally {
  fis.close();
}

可以把上述代码等价地写成：

try (FileInputStream fis = new FileInputStream(file)) {
  // do something
}

• multiple catch

try {
  // do something
} catch (AException e) {
  throw new MyException(e);
} catch (BException e) {
  throw new MyException(e);
}

可以把上述代码等价地写成：

try {
  // do something
} catch (AException | BException e) {
  throw new MyException(e);
}

• 使用示例

try (BufferedReader br = new BufferedReader(…);
     BufferedWriter writer = new BufferedWriter(…)) {// Try-with-resources
// do something
catch ( IOException | XEception e) {// Multiple catch
   // Handle it
} 

三、知识扩展

上面主要是概念性的知识点，接下来结合代码分析实践中的一些选择

3.1 异常处理基本原则

下面的代码反映了异常处理中哪些不当之处？

try {
  // 业务代码
  // …
  Thread.sleep(1000L);
} catch (Exception e) {
  // Ignore it
}

这段代码虽然很短，但是已经违反了异常处理的两个基本原则：

3.1.1 尽量捕获特定异常

第一，尽量不要捕获类似Exception这样通用的异常，而是应该捕获特定异常，在这里是 Thread.sleep()抛出的InterruptedException

这是因为在日常的开发和合作中，读代码的机会往往超过写代码，有义务让自己的代码能够直观地体现出尽量多的信息，而泛泛的Exception恰恰隐藏了我们的目的

另外，要保证程序不会捕获到不希望捕获的异常。比如，可能更希望RuntimeException被扩散出来，而不是被捕获

进一步讲，除非深思熟虑否则不要捕获Throwable或者Error，这样很难保证能够正确程序处理 OutOfMemoryError

3.1.2 不要生吞异常

第二，不要生吞(swallow)异常，这是异常处理中要特别注意的事情，因为很可能会导致非常难以诊断的诡异情况

生吞异常，往往是基于假设这段代码可能不会发生，或者感觉忽略异常是无所谓的，但是千万不要在产品代码做这种假设

如果不把异常抛出来，或者也没有输出到日志(Logger)之类，程序可能在后续代码以不可控的方式结束。没人能够轻易判断究竟是哪里抛出了异常，以及是什么原因产生了异常

3.2 异常处理Throw early, catch late原则

再来看看第二段代码

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

这段代码作为一段实验代码是没有任何问题的，但是在产品代码中通常都不允许这样处理。这是为什么呢？

看看printStackTrace()的文档，开头就是Prints this throwable and its backtrace to the standard error stream。问题就在这里，在稍微复杂一点的生产系统中，标准出错STERR不是个合适的输出选项，因为很难判断出到底输出到哪里去了

尤其是对于分布式系统，如果发生异常但是无法找到堆栈轨迹stacktrace，这纯属是为诊断设置障碍。所以，最好使用产品日志详细地输出到日志系统里

接下来看下面的代码段，体会一下Throw early, catch late原则

public void readPreferences(String fileName){
   //...perform operations... 
  InputStream in = new FileInputStream(fileName);
   //...read the preferences file...
}

如果fileName是null，那么程序就会抛出NullPointerException，但是由于没有第一时间暴露出问题，堆栈信息可能非常令人费解，往往需要相对复杂的定位
这个NPE只是作为例子，实际产品代码中可能是各种情况，比如获取配置失败之类的。在发现问题的时候，第一时间抛出，能够更加清晰地反映问题

可以修改一下，让问题throw early，对应的异常信息就非常直观

public void readPreferences(String filename) {
  Objects. requireNonNull(filename);
  //...perform other operations... 
  InputStream in = new FileInputStream(filename);
   //...read the preferences file...
}

至于catch late，其实是经常苦恼的问题，捕获异常后需要怎么处理呢？
最差的处理方式是前面提到的生吞异常，本质上其实是掩盖问题。如果实在不知道如何处理，可以选择保留原有异常的cause信息，直接再抛出或者构建新的异常抛出去。在更高层面，因为有了清晰的(业务)逻辑，往往会更清楚合适的处理方式是什么

3.3 异常信息原则

有的时候，会根据需要自定义异常，这个时候除了保证提供足够的信息，还有两点需要考虑：

1. 是否需要定义成Checked Exception

因为这种类型设计的初衷更是为了从异常情况恢复，作为异常设计者，往往有充足信息进行分类

2. 避免包含敏感信息

在保证诊断信息足够的同时，也要考虑避免包含敏感信息，因为那样可能导致潜在的安全问题

如果查看Java的标准类库，可能注意到类似java.net.ConnectException，出错信息是类似Connection refused (Connection refused)，而不包含具体的机器名、IP、端口等，一个重要考量就是信息安全。类似的情况在日志中也有，比如，用户数据一般是不可以输出到日志里面的

业界有一种争论或者算是某种程度的共识，Java语言的Checked Exception也许是个设计错误，反对者列举了几点：

• Checked Exception的假设是捕获了异常，然后恢复程序。但是，其实大多数情况下根本就不可能恢复，Checked Exception的使用，已经大大偏离了最初的设计目的
• Checked Exception不兼容functional编程，如果写过Lambda/Stream代码，相信深有体会

很多开源项目，已经采纳了这种实践，比如Spring、Hibernate等

当然，很多人也觉得没有必要矫枉过正，因为确实有一些异常，比如和环境相关的IO、网络等，其实是存在可恢复性的，而且Java已经通过业界的海量实践，证明了其构建高质量软件的能力

3.4 性能因素

从性能角度来审视一下Java的异常处理机制，这里有两个可能会相对昂贵的地方：

• try-catch代码段会产生额外的性能开销

换个角度说，try-catch往往会影响JVM对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的try包住整段的代码

与此同时，利用异常控制代码流程，也不是一个好主意，远比通常意义上的条件语句(if/else、switch)要低效

• 实例化的Exception对栈进行快照

Java每实例化一个Exception，都会对当时的栈进行快照，这是一个相对比较重的操作。如果发生的非常频繁，这个开销可就不能被忽略

所以，对于部分追求极致性能的底层类库，有种方式是尝试创建不进行栈快照的Exception。这本身也存在争议，因为这样做的假设在于，我创建异常时知道未来是否需要堆栈。问题是，实际上小范围或许可能，但是在大规模项目中这么做可能不是个理智的选择。如果需要堆栈，但又没有收集这些信息，在复杂情况下，尤其是类似微服务这种分布式系统，会大大增加诊断的难度

当服务出现反应变慢、吞吐量下降的时候，检查发生最频繁的Exception也是一种思路

综上，从一个常见的异常处理概念问题，简单总结Java异常处理的机制，并结合代码分析了一些普遍认可的最佳实践，以及业界最新的一些异常使用共识。最后，分析了异常性能开销