请对比Exception和Error,另外,运行时异常与异常有什么区别?
典型回答:
Exception和Error都是继承了Throwable类,在Java中只有Throwable类型的实例可以被抛出(thorow)或者捕获(catch),它是异常处理机制的基本组成类型
Exception和Error体现了Java平台设计者对不同异常情况的分类.Exception是程序正常运行中,可以预料的意外情况,可能并且应该被捕获,进行相应处理.
Exception是指在正常情况下,不大可能出现的情况,绝大部分的Error都会导致程序(比如JVM自身)处于非正常的,不可恢复状态.既然是非正常情况,所以不便于也不需要捕获,常见的比如OutOfMemoryError之类,都是Error的子类
Exception又分为可检查(checked)异常和不检查(unchecked)异常,可检查异常在源代码里必须显式地进行捕获处理,这是编译器检查的一部分,前面的是不可检查的Error,是Throwable不是Exception
不检查异常就是所谓的运行时异常,类似NullPointerException,ArrayIndexOutOfBoundsException之类,通常是可以编码避免的逻辑错误,具体根据需要是判断是否需要捕获,并不会在编译器强制要求
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 backstrace to the standard error stream".问题就在这里,再稍微复杂一点的生产系统中,标准出错(STERR)不是个合适的输出选项,因为很难判断出输出到哪里去了.
尤其是对于分布式系统,如果发生异常,但是无法找到堆栈轨迹(stacktrace),这纯属为诊断设置障碍.所以,最好使用产品日志,详细的输出到日志系统里.
有的时候,我们会根据需要自定义异常,这个时候除了提供足够的信息,还有两点需要考虑:
-
是否需要定义成Checked Exception,因为这种类型设计的初衷更是为了从异常中恢复,作为异常设计者,我们往往有充足信息进行分类
-
在保证诊断信息足够的同时,也要考虑避免包含敏感信息,因为那样可能导致潜在的安全问题.如果我们看Java的标准类库你可能注意到类似java.net.ConnectException,出错信息是类似与"Connection refused(Connection refused)",而不包含具体的机器名,IP,端口等,一个重要考量就是信息安全,类似的情况在日志中也有,比如,用户数据一般是不可以输出到日志里面的
业界有一种争论(甚至可以算是某种程度的共识),Java语言的Checked Exception也许是个设计错误,反对者列举了几点:
-
Checked Exception的假设是我们捕获了异常,然后恢复程序,但是,其实我们大多数情况下,根本就不可能恢复.Checked Exception的使用,已经大大偏离了最初的设计目的的.
-
Checked Exception不兼容functional编程
我们从性能角度来审视以下Java的异常处理机制,这里有两个可能会相对昂贵的地方:
-
try-catch代码段会产生额外的性能开销,或者换个角度来说,他往往会影响JVM对代码进行优化,所以建议仅仅捕获有必要的代码段,尽量不要一个大的try包住整段的代码;与此同时,利用一场控制代码流程,也不是一个好主意,远比我们通常意义上的条件语句(if/esle,switch)要低效
-
Java每实例化一个Exception,都会对当时的栈进行快照,这是一个相对比较重的操作.如果发生的非常频繁,这个开销可就不能被忽略了.
所以,对于部分追求极致性能的底层类库,有种方式是尝试创建不进行栈快照的Exception.这本身也存在争议,因为这样的假设在于,我创建异常时知道未来是否需要堆栈.问题是,实际上可能吗?小范围或许可能,但是在大规模项目中,这么做可能不是个理智的选择.如果需要堆栈,但又没有收集这些信息,在复杂情况下,尤其是类似为服务这种分布式系统,这会大大增加诊断的难度.
当我们的服务出现反应变慢,吞吐量下降的时候,检查发送最频繁的Exception也是一种思路
本文转载自极客时间杨晓峰
本文深入探讨了Java中Exception和Error的区别,解释了运行时异常与异常的基本概念。通过实例,详细分析了异常处理的原则,包括捕获特定异常、避免生吞异常以及自定义异常时的注意事项。
159

被折叠的 条评论
为什么被折叠?



