本人总结:

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语句，这个修改也作用于返回值上，

⑦误将异常用于控制流。

⑧如无必要，勿用异常。