1、请对比Exception和Error,另外,运行时异常与一般异常有什么区别?
典型回答:
Exception和Error都是继承了Throwable类,在Java中只有Throwable类型的实例才可以被抛出(throw)或者捕获(catch),它是异常处理机制的基本组成类型。
Exception和Error体现了Java平台设计者对不同异常情况的分类。Exception是程序正常运行中,可以预料的意外情况,可能并且应该被捕获,进行相应处理。
Error是指在正常情况下,不大可能出现的情况,绝大部分的Error都会导致程序(比如JVM自身)处于非正常的、不可恢复状态。既然是非正常情况,所以不便于也不需要捕获,常见的比如OutOfMemoryError之类,都是Error的子类。
Exception又分为可检查(checked)异常和不检查(unchecked)异常,可检查异常在源代码里必须显式地进行捕获处理,这是编译期检查的一部分。前面我介绍的不可查的Error,是Throwable不是Exception。
不检查异常就是所谓的运行时异常,类似 NullPointerException、ArrayIndexOutOfBoundsException之类,通常是可以编码避免的逻辑错误,具体根据需要来判断是否需要捕获,并不会在编译期强制要求。考点分析
考点分析
第一,理解Throwable、Exception、Error的设计和分类。比如,掌握那些应用最为广泛的子类,以及如何自定义异常等。
第二,理解Java语言中操作Throwable的元素和实践。掌握最基本的语法是必须的,如try-catch-finally块,throw、throws关键字等。
引入了一些更加便利的特性,比如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
第二,不要生吞(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){
//...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信息,直接再抛出或者构建新的异常抛出去。在更高层面,因为有了清晰的(业务)逻辑,往往会更清楚合适的处理方式是什么。
自定义异常
有的时候,我们会根据需要自定义异常,这个时候除了保证提供足够的信息,还有两点需要考虑:
- 是否需要定义成Checked Exception,因为这种类型设计的初衷更是为了从异常情况恢复,作为异常设计者,我们往往有充足信息进行分类。
- 在保证诊断信息足够的同时,也要考虑避免包含敏感信息,因为那样可能导致潜在的安全问题。如果我们看Java的标准类库,你可能注意到类似java.net.ConnectException,出错信息是类似“ Connection refused (Connection refused)”,而不包含具体的机器名、IP、端口等,一个重要考量就是信息安全。类似的情况在日志中也有,比如,用户数据一般是不可以输出到日志里面的。
2、exception和error
Exception家族我们恐怕见的不少,但是error家族我们可能就没什么印象了,下面我来说说这两个类的区别:
Error(错误):是程序无法处理的错误,表示运行应用程序中较严重问题。大多数的错误与代码编写者执行的操作无关,而是表示代码运行时 JVM(Java 虚拟机)出现的问题。例如,Java虚拟机运行错误(Virtual MachineError),当 JVM 不再有继续执行操作所需的内存资源时,将出现 OutOfMemoryError。这些异常发生时,Java虚拟机(JVM)一般会选择线程终止。这些错误表示故障发生于虚拟机自身、或者发生在虚拟机试图执行应用时,如Java虚拟机运行错误(Virtual MachineError)、类定义错误(NoClassDefFoundError)等。这些错误是不可查的,因为它们在应用程序的控制和处理能力之外,而且绝大多数是程序运行时不允许出现的状况。对于设计合理的应用程序来说,即使确实发生了错误,本质上也不应该试图去处理它所引起的异常状况。在 Java中,错误通过Error的子类描述。
个人理解:出现Error错误一般不是由于你编写的代码出现问题,而是由于JVM运行你这段代码出现了问题,比如堆溢出,配置文件出错等,这些你是无法人为的在你代码里可以保证的,必须要额外的去操作,重新配置虚拟机,修改配置文件等等。
Exception(异常):是程序本身可以处理的异常。也就是你常见的空指针异常(NullPointerException),数组超出范围异常(IndexOutOfBoundsException)等等。
通常,Java的异常(包括Exception和Error)分为检查异常(checked exceptions)和非检查的异常(unchecked exceptions)。
一、检查异常(checked exceptions)
什么是检查异常?
答:就是编译器要求你必须处置的异常。不知道你编程的时候有没有遇到过,你写的某段代码,编译器要求你必须要对这段代码try...catch,或者throws exception,如果你遇见过,没错,这就是检查异常,也就是说,你代码还没运行呢,编译器就会检查你的代码,会不会出现异常,要求你对可能出现的异常必须做出相应的处理。
对检查异常(checked exception)的几种处理方式:
1、继续抛出,消极的方法,一直可以抛到java虚拟机来处理,就是通过throws exception抛出。
2、用try...catch捕获
注意,对于检查的异常必须处理,或者必须捕获或者必须抛出
如何区分什么是检查异常呢?
除了RuntimeException与其子类,以及错误(Error),其他的都是检查异常(绝对的大家族)。
二、非检查异常(unchecked exceptions)
什么是非检查异常?
答:编译器不要求强制处置的异常,虽然你有可能出现错误,但是我不会在编译的时候检查,没必要,也不可能。为什么呢?你想想非检查异常都有哪些?NullPointerException,IndexOutOfBoundsException,VirtualMachineError等,这些异常你编译的时候检查吗?那我还要不要运行了,等死人啊。再说了,明明可以运行时检查,都在编译的时候检查,你写的代码还能看吗?而且有些异常只能在运行时才能检查出来,比如空指针,堆溢出等。
对未检查的异常(unchecked exception )的几种处理方式:
1、捕获
2、继续抛出
3、不处理
一般我们是不处理的,因为你很难判断会出什么问题,而且有些异常你也无法运行时处理,比如空指针,需要人手动的去查找。
而且,捕捉异常并处理的代价远远大于直接抛出。
如何区分什么是非检查异常呢?
RuntimeException与其子类,以及错误(Error)。
顺便说一下运行时异常和非运行时异常。
刚才我们是从Exception和Error整体来划分的,现在我们可以对Exception异常进行划分,它可分为运行时异常和非运行时异常。
一、运行时异常
都是RuntimeException类及其子类异常,如NullPointerException(空指针异常)、IndexOutOfBoundsException(下标越界异常)等,这些异常是非检查异常,程序中可以选择捕获处理,也可以不处理。这些异常一般是由程序逻辑错误引起的,程序应该从逻辑角度尽可能避免这类异常的发生。
运行时异常的特点是Java编译器不会检查它,也就是说,当程序中可能出现这类异常,即使没有用try-catch语句捕获它,也没有用throws子句声明抛出它,也会编译通过。
二、非运行时异常
是RuntimeException以外的异常,类型上都属于Exception类及其子类。从程序语法角度讲是必须进行处理的异常,如果不处理,程序就不能编译通过。如IOException、SQLException等以及用户自定义的Exception异常,一般情况下不要自定义检查异常。
3、NoClassDefFoundError和ClassNotFoundException有什么区别
在类加载的过程中我们最常遇到的异常就是:
-
ClassNotFoundException
- NoClassDefFoundError
1、 ClassNotFoundException
ClassNotFoundException
告诉我们使用类加载器加载某个类的时候,发现所有的path下面都没有找到,从启动类路径,扩展类路径到当前的classpath下全部没有找到,就会抛出上面的异常,最常见的例子就是加载JDBC驱动包的时候,它的依赖jar并不在classpath里面,如下:
package class_loader.exception;
public class ExceptionTest {
public static void main(String[] args)throws Exception {
Class.forName("oracle.jdbc.driver.OracleDriver");
}
}
就会抛出异常ClassNotFoundException:
Exception in thread "main" java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at class_loader.exception.ExceptionTest.main(ExceptionTest.java:8)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
这种情况下,其实就是类找不到,通常在执行下面的方法时容易抛出:
Class.forName()
ClassLoader.loadClass()
ClassLoader.findSystemClass()
2、NoClassDefFoundError
NoClassDefFoundError这个异常,严格来说不能叫异常,这种级别属于JVM的ERROR错误了,其严重级别要更高。
这个错误,主要有两种情况:
(1)编译时存在某个类,但是运行时却找不到,如下:
public class A {
public void hello(){
System.out.println("A hello");
}
}
class B {
public static void main(String[] args) {
A a=new A();
}
}
上面的Java类编译后会生成两个类文件,一个A.class,一个B.class,现在我在编译后,删掉了A的class文件,然后直接执行B的main方法,就会抛出 NoClassDefFoundError错误,因为当执行到 A a=new A();这一步的时候,jvm认为这个类肯定在当前的classpath里面的,要不然编译都不会通过,更不用提执行了。既然它存在,那么在jvm里面一定能找到,如果不能找到,那就说明出大事了,因为编译和运行不一致,所以直接抛出这个ERROR,代表问题很严重。
(2)第二种情况,类根本就没有初始化成功,结果你还把它当做正常类使用,所以这事也不小,必须抛出ERROR告诉你不能再使用了。
看下面的一段代码:
public class Loading {
static double i=1/0;//故意使得类初始化失败.
public static void print(){
System.out.println("123");
}
}
调用如下:
public static void main(String[] args) {
try {
double i=Loading.i;
}catch (Throwable e){
//此处,必须用Throwable,用Exception会直接退出.
System.out.println(e);
}
//继续使用.
Loading.print();
}
结果如下:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class class_loader.exception.Loading
java.lang.ExceptionInInitializerError
at class_loader.exception.NoClassFoundErrorTest.main(NoClassFoundErrorTest.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
注意这种情况比较特殊,并不是因为编译时和运行时环境不一致导致的,而是对于一个类如果初始化失败后,你还继续使用,那么JVM会认为是不正常的,由于它第一次调用已经失败,JVM就会假设后面继续调用肯定仍然会失败,所以直接抛ERROR给客户端。
这里需要注意,类初始化失败的异常是:
java.lang.ExceptionInInitializerError
也是一个严重级别的错误。
总结
直接采用反射或者类加载器的loadClass方法去动态加载一个所有classpath里面的都不存在的类,类加载器在运行时的load阶段就会直接抛出ClassNotFoundException异常。此外jvm认为这个异常是可以被预知的需要提前被check。对于另一种请情况,如果在编译时候正常,但在运行时执行new关键词的时候,发现依赖类找不到,或者是对于初始化失败的一个类,再次访问其静态成员或者方法,那么会直接抛出NoClassDefFoundError错误。这两种异常本质上的侧重点还是不一样的,前者侧重在类加载器加载阶段找不到类信息,后者则侧重在使用阶段时却出现了问题比如实例化依赖类找不到或者类本身就初始化失败了。
3、你了解哪些Error、Exception或者RuntimeException?