Java核心技术Exception和Error的区别
Posted sysu_lluozh
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Java核心技术Exception和Error的区别相关的知识,希望对你有一定的参考价值。
Java语言在设计之初就提供相对完善的异常处理机制,这种机制大大降低了编写和维护可靠程序的门槛,如今异常处理机制已成为编程语言的标配
有两个问题:
- 对比
Exception
和Error
- 运行时异常与一般异常有什么区别?
一、典型回答
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:
- throw是语句抛出一个异常,一般是在代码块的内部,当程序出现某种逻辑错误时由程序员主动抛出某种特定类型的异常
- 定义在方法体内
- 创建的是一个异常对象
- 确定了发生哪种异常才可以使用
throws:
- 在方法参数列表后,throws后可以跟着多个异常名,表示抛出的异常用逗号隔开
- 表示向调用该类的位置抛出异常,不在该类解决
- 可能发生哪种异常throws用在方法声明后面,跟的是异常类名
其他异同:
- throw用在方法体内,跟的是异常对象名,且只能抛出一个异常对象名,throws可以跟多个异常类名,用逗号隔开
- throw表示抛出异常由方法体内的语句处理,throws表示抛出异常由该方法的调用者来处理
- throw表示抛出了异常,执行throw则一定抛出了某种异常,throws表示出现异常的一种可能性,并不一定会发生这些异常,
2.2.2 便利特性
异常处理代码比较繁琐,比如需要写很多千篇一律的捕获代码,或者在finally里面做一些资源回收工作
随着Java语言的发展,引入了一些更加便利的特性:
- 比如
try-with-resources
和multiple catch
,在编译时期自动生成相应的处理逻辑 - 比如自动按照约定俗成
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 异常信息原则
有的时候,会根据需要自定义异常,这个时候除了保证提供足够的信息,还有两点需要考虑:
- 是否需要定义成Checked Exception
因为这种类型设计的初衷更是为了从异常情况恢复,作为异常设计者,往往有充足信息进行分类
- 避免包含敏感信息
在保证诊断信息足够的同时,也要考虑避免包含敏感信息,因为那样可能导致潜在的安全问题
如果查看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异常处理的机制,并结合代码分析了一些普遍认可的最佳实践,以及业界最新的一些异常使用共识。最后,分析了异常性能开销
以上是关于Java核心技术Exception和Error的区别的主要内容,如果未能解决你的问题,请参考以下文章