1.异常机制
上面的异常继承体系中,Error和RuntimeException是非检查型异常(Unchecked Exception),也就是不需要catch语句去捕获的异常;其他异常,则需要程序员手动去处理。
接下来让我们通过字节码去一探究竟这种异常处理。
2.异常表
我们先来看一个实例
package sandwich.test5;
/**
* @author 公众号:IT三明治
* @date 2021/6/13
*/
public class SynchronizedTest {
synchronized void fun1(){
System.out.println("fun1");
}
static synchronized void fun2(){
System.out.println("fun2");
}
final Object lock=new Object();
void lockProcess(){
synchronized (lock){
System.out.println("lock");
}
}
}
反编译得到lockProcess的信息
在synchronized生成的字节码中,其实包含两条monitorexit指令,是为了保证所有的异常条件,都能够退出。
编译后的字节码,有一个叫Exception table的异常表,里面的每一行数据,都是一个异常处理器。
from: 指定字节码索引的开始位置
to: 指定字节码索引的结束位置
target: 异常处理的起始位置
type:异常类型
也就是说,只要在from和to之间发生了异常,就会跳到target所指定的位置。
第一条monitorexit(16)在异常表第一条的范围中,如果异常, 能够跳到第20行。
第二条monitorexit(22)在异常表第二条的范围中,如果异常,能够跳转到第20行。
由以上java代码可以看到,我们不需要主动去catch exception. 也能自动处理两个any类型的异常
如果用jclasslib插件观察,也很方便。
3. Finally
通常我们在做一些文件读取的时候,都会在finally代码块中关闭流,以避免内存的溢出。关于这个场景,我们再分析一下下面这段代码的异常表。
package sandwich.test5;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStream;
/**
* @author 公众号:IT三明治
* @date 2021/6/13
*/
public class StreamTest {
public void read() {
InputStream in = null;
try {
in = new FileInputStream("Test.java");
} catch (FileNotFoundException e) {
e.printStackTrace();
} finally {
if (null != in) {
try {
in.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}
上面的代码,捕获了一个FileNotFoundException异常,然后在finally中捕获了IOException异常。当我们分析字节码的时候,却发现了一个有意思的地 方:IOException足足出现了三次
Java编译器使用了一种比较傻的方式来组织finally的字节码,它分别在try、catch的正常执行路径上,复制一份finally代码,追加在正常执行逻辑的后面。同时,再复制一份到其他异常执行逻辑的出口处。
再看一个例子
package sandwich.test5;
/**
* @author 公众号:IT三明治
* @date 2021/6/13
*/
public class NoError {
public static void main(String[] args) {
NoError noError = new NoError();
int result = noError.read();
System.out.println(result);
}
private int read() {
try {
int a = 13/0;
return a;
} finally {
return 1;
}
}
}
这段代码不报错的原因,都可以在字节码中找到答案
通过程序的字节码,可以看到,异常之后,直接跳转到序号9了。没有输出错误的字节码。