java核心技术——Exception和Error的区别

ExceptionError 都是继承了 Throwable 类,在 Java 中只有 Throwable 类型的实例才可以被抛出(throw)或者捕获(catch),它是异常处理机制的基本组成类型。

ExceptionError 体现了 Java 平台设计者对不同异常情况的分类。Exception 是程序正常运行中,可以预料的意外情况,可能并且应该被捕获,进行相应处理。

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

Exception 又分为可检查(checked)异常和不检查(unchecked)异常,可检查异常在源代码里必须显式地进行捕获处理,这是编译期检查的一部分。前面我介绍的不可查的 Error,是 Throwable 不是 Exception

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

考点分析:

第一,理解 ThrowableExceptionError的设计和分类。比如,掌握那些应用最为广泛的子类,以及如何自定义异常等。

其中有些子类型,最好重点理解一下,比如 NoClassDefFoundError 和 ClassNotFoundException 有什么区别,这也是个经典的入门题目。

第二,理解 Java 语言中操作 Throwable 的元素和实践。掌握最基本的语法是必须的,如 try-catch-finally 块,throw、throws 关键字等。与此同时,也要懂得如何处理典型场景。

异常处理代码比较繁琐,比如我们需要写很多千篇一律的捕获代码,或者在 finally 里面做一些资源回收工作。随着 Java 语言的发展,引入了一些更加便利的特性,比如 try-with-resources 和 multiple catch,具体可以参考下面的代码段。在编译时期,会自动生成相应的处理逻辑,比如,自动按照约定俗成 close 那些扩展了 AutoCloseable 或者 Closeable 的对象。

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

知识扩张:

前面谈的大多是概念性的东西,下面我们来看一些实战中的例子。

先来看第一个吧,下面的代码反映了异常处理中哪些不当之处?

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

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

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

这是因为在日常的开发和合作中,我们读代码的机会往往超过写代码,软件工程是门协作的艺术,所以我们有义务让自己的代码能够直观地体现出尽量多的信息,而泛泛的 Exception 之类,恰恰隐藏了我们的目的。另外,我们也要保证程序不会捕获到我们不希望捕获的异常。比如,你可能更希望 RuntimeException 被扩散出来,而不是被捕获。

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

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

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

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

再来看看第二段代码

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){
    InputStream in = new FileInputStream(fileName);
}

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

我们可以修改一下,让问题“throw early”,对应的异常信息就非常直观了。

public void readPreferences(String filename) {
    Objects. requireNonNull(filename);
    InputStream in = new FileInputStream(filename);
}

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

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

  1. 是否需要定义成 Checked Exception,因为这种类型设计的初衷更是为了从异常情况恢复,作为异常设计者,我们往往有充足信息进行分类。
  2. 在保证诊断信息足够的同时,也要考虑避免包含敏感信息,因为那样可能导致潜在的安全问题。如果我们看 Java 的标准类库,你可能注意到类似java.net.ConnectException,出错信息是类似Connection refused (Connection refused),而不包含具体的机器名、IP、端口等,一个重要考量就是信息安全。类似的情况在日志中也有,比如,用户数据一般是不可以输出到日志里面的。

业界有一种争论(甚至可以算是某种程度的共识),Java 语言的 Checked Exception 也许是个设计错误,反对者列举了几点:

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

很多开源项目,已经采纳了这种实践,比如 Spring、Hibernate 等,甚至反映在新的编程语言设计中,比如 Scala 等。如果有兴趣,你可以参考: http://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/

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

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

  1. try-catch 代码段会产生额外的性能开销,或者换个角度说,它往往会影响 JVM 对代码进行优化,所以建议仅捕获有必要的代码段,尽量不要一个大的 try 包住整段的代码;与此同时,利用异常控制代码流程,也不是一个好主意,远比我们通常意义上的条件语句(if/else、switch)要低效。
  2. Java 每实例化一个 Exception,都会对当时的栈进行快照,这是一个相对比较重的操作。如果发生的非常频繁,这个开销可就不能被忽略了。

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

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

文章的最后,知识的挖掘还没有到最后,我们可以思考一个问题: 对于异常处理编程,不同的编程范式也会影响到异常处理策略,比如,现在非常火热的反应式编程(Reactive Stream),因为其本身是异步、基于事件机制的,所以出现异常情况,决不能简单抛出去;另外,由于代码堆栈不再是同步调用那种垂直的结构,这里的异常处理和日志需要更加小心,我们看到的往往是特定 executor 的堆栈,而不是业务方法调用关系。对于这种情况,你有什么好的办法吗?

可在留言区一起探讨哦,还有很多相关知识没有罗列到,也可以在留言区评论。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯移动品质中心TMQ的专栏

小说书架内容质量自动化测试

一.项目背景 小说书架的产品思路是:在手机QQ浏览器这个平台上,给用户提供一个小说书架这样的小说阅读入口。通过这个入口阅读到的小说,是后台将从其它网页中抽取到...

2305
来自专栏Vamei实验室

编程异闻录

作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明。谢谢!

1062
来自专栏Linyb极客之路

软件开发中的原则

一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。(Every object should have a single responsibilit...

805
来自专栏人工智能LeadAI

python与数据科学应用

数据科学简介与应用 数据科学主要以统计学、机器学习、数据可视化以及(某一)领域知识为理论基础,其主要研究内容包括数据科学基础理论、数据预处理、数据计算和数据管...

3745
来自专栏同步博客

设计模式六大原则

  单一职责原则又称为单一功能原则,即不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。

774
来自专栏Java Web

Java 8——函数式数据处理(流)

本篇内容大部分来自《Java 8实战》 流是什么? 流是Java API的新成员,它允许你以声明性方式处理数据集合(通过查询语句来表达,而不是临时写一个实现)...

3185
来自专栏Java面试通关手册

一份送给Java初学者的指南

我自己总结的Java学习的系统知识点以及面试问题,目前已经开源,会一直完善下去,欢迎建议和指导欢迎Star: https://github.com/Snailc...

1513
来自专栏Java技术栈

Java架构师必须知道的 6 大设计原则

原文:www.cnblogs.com/pengdai/p/9151800.html

1463
来自专栏机器学习和数学

[编程经验] Python中处理时间的方法小结

Python有非常完善的时间处理方法,常用的module有datetime, time。接下来主要介绍几个概念和一些常用的方法。 # UTC时间 UTC时间是...

3189
来自专栏我杨某人的青春满是悔恨

人生充满选择,编程也是

人生在世,我们每天都需要进行三项重大选择:早餐吃什么,午餐吃什么,晚餐吃什么。这一度让我感到非常为难,于是我养成了一个习惯,只要在附近的餐馆发现了几种还不错的食...

991

扫码关注云+社区

领取腾讯云代金券