本人总结:
Exception和Error:正常问题和意外问题,以自行车举例:没气和爆胎.
①理解Throwable,Exception,Error的设计和分类.
②掌握哪些应用最广泛的子类,
③如何定义异常.
解决不了异常的捕获不如抛出.
捕获不了异常的捕获不是好捕获,什么异常都捕获的捕获不是好捕获,解决不了异常的捕获一定是坏捕获.
捕获不是俄罗斯转盘,99分的捕获不如抛出,因为缺的1分可能是致命的.
世界上存在永远不会出错的程序吗?这也许只会出现在程序员的梦中.随着编程语言和软件的诞生,异常情况就如影随形的纠缠着我们,只有正确吃力好意外情况,才能保证程序的可靠性.
java语言在设计之初就提供了相对完整的异常处理机制,这也是java得意大行其道的原因之一,因为这种机制大大降低了编写和维护可靠程序的门槛.如今,异常处理机制已经成为现代编程语言的标配.
今天的问题:
请对比Exception和Error,另外,运行时异常与一般异常有什么区别?
经典回答
Exception和Error都是继承了Throwable类,在java中只有Throwable类型的实例才可以被抛出(throw)或者捕获(catch),它是异常处理机制的基本组成类型.
Exception和Error体现了java平台设计者对不同异常情况的分类.
Exception是程序正常执行中,可以预料的意外情况,应该被捕获,进行相应处理.
Error是指正常情况下,不大可能出现的情况.绝大部分的Error都会导致程序(比如JVM自身)处于非正常,不可恢复状态.既然是非正常状态因此也不便于,不需要捕获,常见如:outofmemoryerror等Error子类.
exception分为:可检查异常和不检查异常.
可检查异常:在源代码中必须显示的进行捕获处理,这是编译期检查的一部分.
不检查异常:(运行时异常):例如空值越界.通常是通过编码可以避免的逻辑错误,根据具体需求判断是否捕获,并不会在编译期强制要求.
考点分析:
分析Exception和Error的区别,从概念角度考察了java处理机制,总的来说,还处于理解的层面,面试者只要解释清楚就好.
我们在日常编程中,如何处理好异常是比较考验功底的,我觉得需要掌握两个方面
第一,理解Throwable,Exception,Error的设计和分类.比如,掌握哪些应用最广泛的子类,以及如何定义异常.
很多面试官会进一步追问一些细节,比如,你了解哪些Exception,Error,RunTimeException?我简单画了一个图以供参考.
重点理解NoClassDefFoundError和ClassNotFoundException有什么区别,也是经典的入门题目.
第二,理解java语言中操作Throwable的元素和实践.要掌握最基本的语法.如try-catch-finally块,throw,throws关键字等.同时,懂得解决经典场景问题.
异常处理代码比较繁琐,如要写千篇一律的捕获代码,或在finally做一些资源回收工作.随着java语言的发展引入一些更便利的特征,比如 try-with-resources和multiple catch,在编译时期会自动生成对应的处理逻辑.例如,自动按约定俗成close哪些拓展了AutoCloseable或者Closeable的对象.
知识拓展
前面谈的大多数是概念性的知识,下面谈谈实践中的选择,我会结合带吗进行分析.
第一个:下面代码反应异常处理中哪些不当之处:
try{ //业务代码 Thread.sleep(1000L) }catch(Exception e){ //lgnore it }
这段代码很短,但违反了两个基本原则
第一:尽量不要捕获Exception这样的通用异常,而是要捕获特定异常,其中Thread.sleep()抛出InterruotedException.
这是因为在日常的开发和合作中,我们读代码的机会往往超过写代码.软件工程是一门协作的艺术,所以我们有义务让自己的代码直观体现尽量多的信息,但是泛泛的Exception之类,恰恰隐藏了我们的目的.另外,我们需要保证程序不会捕获我们不希望的异常.比如我们希望RuntimeException被扩散出去,而不是被捕获.更进一步讲,除非经过深思熟虑,否则不要捕获Throwable或者Error,因为很难保证正确处理OutOfMemoryError
第二,不要生吞异常,就是没有完整解决异常.catch里的内容没有解决try抛出的问题.这样可能导致难以诊断的诡异情况.
生吞异常,基于假设这个异常不会发生,或者觉得忽略异常是无所谓的,但是千万不要在产品代码做这种假设.
如果我们不把异常抛出来,或者也没有输出到日志之类,程序可能在后续代码以不可控方式结束.没人可以判断究竟哪里抛出异常,以及什么原因导致异常.
第二个:
try{ //业务 }catch(IOException e){ e.printStackTrace(); }
这段代码作为一段实验代码没有任何问题,但在产品代码中通常不允许这样处理.因为标准出错(STERR)不是一个合适的输出选项,因为很难判断出到底输出到哪里去了.
公众号:代码荣耀
在java世界里,异常的出现让我们编写的程序运行起来更加健壮,同时为程序在调试,运行期间发生的一些意外情况,提供补救机会,即使遇到一些严重错误而无法补救,异常也会非常忠实的记录所发生的一切,
①不要推诿或延迟异常处理,就地解决最好,并且要进行实实在在的处理,而不是只是捕捉不做动作,
②一个函数尽管抛出了多个异常,但是只有一个异常可被传播到客户端,最后被抛出的异常是唯一被调用端接收的异常,其他异常会被忽略,如果调用端要知道造成失败的最初原因,程序之中就不能掩盖任何异常.
③不要在finally代码块中处理返回值.
④按照我们程序员的惯性认知:当遇到return语句的时候,执行函数会立刻返回.但是,在java语言中,如果存在finally就会有例外,除了return语句,try代码块的break或continue语句也可能使控制权进入finally代码块.
⑤请勿在try代码块中调用return,break,continue语句.万一无法避免,一定要确保finally的存在不会改变函数的返回值.
⑥函数返回值有两种类型：值类型与对象引用。对于对象引用要特别小心，如果在finally代码块中对函数返回的对象成员属性进行修改，即使不在finally块中显式调用return语句，这个修改也作用于返回值上，
⑦误将异常用于控制流。
⑧如无必要，勿用异常。