(JavaCard) JVM的异常控制器原理，以及编译器对finally的特殊处理

鉴于此处的机制，在卡端和上层大同小异，以上层代码作为例子。

JVM == JCVM

JRE == JCRE

JVM对异常的处理主要是基于异常表(Exception Table)，每个包含了try的方法在编译后除字节码外，都会产生一个附加的数据结构--异常表，

异常表结构：

{

{PC:BEGIN, PC:END, PC:HANDLER, EXCEPTION-TYPE}

.................

}

PC:BEGIN-PC:END 代表着异常发生的PC值的范围

EXCEPTION-TYPE 代表着异常捕获的类型

PC:HANDLER 代表着异常处理的指针

异常表的产生：

异常表是多组数据，每个catch都会产生一个记录。举个例子

class MyException extends Exception {MyException(String str){super(str)}}

class TestException {

static void f() throws MyException{
throw err;
}
static void g() throws MyException{
try {
f();
}
catch(MyException e) {

int a = 0; //pc = 6
}

catch(Exception e) {

int a = 0; //pc = 10
}

}

方法f是可能产生异常的函数，在方法g中使用了try/catch进行了调用。

此时g产生的异常表为：

Exception Table:
[pc: 0, pc: 3] -> 6 when : MyException
[pc: 0, pc: 3] -> 10 when : Exception

异常表的使用：

当JVM的函数产生异常后（athrow指令）：

1.JVM会在当前Frame的Exception Table里面逐条查找PC范围和异常类型符合*的记录。并将PC跳转到对应的异常处理的位置上。

注意：类型符合不是完全匹配，而是符合向上原则，即父类的catch可以捕获子类的对象即 e instance of CLASS。

2.如果当前Frame不存在Exception Table, 或者在Exception Table里找不到匹配的记录，则当前Frame出栈，把当前Frame设置成上一个Frame，获得新的当前pc和当前异常表。

3.继续执行（1），直到JAVA STACK到达栈底还不能匹配，则异常未处理，抛出到JRE。

finally的特殊处理。

我们知道java有个关键字finally，这个关键字在Javacard里面也是支持的。此关键字的作用是不管异常是否被catch到，都要执行到。具体下来，就有几种情况：
1.异常没有被catch到。
2.异常被catch到，并处理。
3.异常被catch到，但又被rethrow了。
结合上面的关于异常表的理解，我们很容易困惑finally在流程上是怎么保证在以上三种情况下执行的。JVM是否要为finally的这种情况作出特殊处理。经过分析后，我欣慰的发现java的编译器已经在字节码层解决了这个问题（虽然方法相当的笨重）
Java编译器把finally认为是一个小的inline函数，实施的是指令替换策略，我们用下面的典型例子对照字节码来测试一下。

代码如下：
class MyException extends Exception {
MyException(String str) {
super(str);
}
}

public class TestException {
static void Mod() {}
static void Mod1() {}
static void Mod2() {}
static void Mod3() {}

static void f() throws MyException {
throw new MyException("");
}

static void g() throws Exception {
try {
f();
Mod();
} catch (MyException e) {
Mod1();

} catch (Exception e) {
Mod2();
throw e;
} finally {
Mod3();
}
}

public static void main(String[] args) {

try {
g();
} catch (Exception e) {
}
}
}

其中方法g的字节码如下：
// Method descriptor #6 ()V
// Stack: 1, Locals: 2
static void g() throws java.lang.Exception;
0 invokestatic TestException.f() : void [30]
3 invokestatic TestException.Mod() : void [32]
6 goto 31
9 astore_0 [e]
10 invokestatic TestException.Mod1() : void [34]
13 invokestatic TestException.Mod3() : void [36]
16 goto 34
19 astore_0 [e]
20 invokestatic TestException.Mod2() : void [38]
23 aload_0 [e]
24 athrow
25 astore_1
26 invokestatic TestException.Mod3() : void [36]
29 aload_1
30 athrow
31 invokestatic TestException.Mod3() : void [36]
34 return
Exception Table:
[pc: 0, pc: 6] -> 9 when : MyException
[pc: 0, pc: 6] -> 19 when : java.lang.Exception
[pc: 0, pc: 13] -> 25 when : any
[pc: 19, pc: 25] -> 25 when : any

可以看到，在增加了finally关键字后，finally内的过程被作为内联函数复制到Exception Table增加了两个类型为any的记录。
流程为：
1.当方法f没有抛出异常的时候，
执行完try块后，goto 31。此处的finally代码被直接编译，顺序执行。
3.当方法f抛出了catch不支持的类型异常的时候，
异常处理器分析Exception Table, 得到匹配记录 [pc: 0, pc: 13] -> 25 when : any 捕获了异常
pc跳转到25，在复制了finally段字节码后，复制捕获的异常再次抛出（ 30 athrow）。
而这个新异常则不能在Exception Table里面得到匹配，被直接抛往栈的上层。
2.当方法f抛出了MyException类型的异常后，
异常处理器分析Exception Table，得到匹配记录 [pc: 0, pc: 6] -> 9 when : MyException 捕获了异常
pc跳转到9执行catch(MyException e)段的内容，并将finally内的字节码复制到catch段的字节码后，执行后跳转到结束。
3.当方法f抛出了Exception类型的异常后
异常处理器分析Exception Table, 得到匹配记录[pc: 0, pc: 6] -> 19 when : java.lang.Exception 捕获了异常
pc跳转到19执行catch(Exception e)段的内容，由于段内rethrow了异常（24 athrow）再次出发异常处理器
异常处理器分析Exception Table，得到匹配记录[pc: 19, pc: 25] -> 25 when : any 捕获了异常
pc跳转到25在复制了finally段字节码后，复制捕获的异常再次抛出（ 30 athrow）。

综合以上流程，字节码的处理完全符合标准的异常处理流程JVM并不需要为此机制作出改动。编译器通过内联函数和扩展异常表来实现的这个过程。
可以这么理解finally，
再有异常发生的时候，可以理解为一个可以捕获方法内任何异常（包含try块中的异常和catch块中的异常）并自动重新抛出的catch段。
在没有异常，或者异常被捕获的过程，以字节码内联的方式将段内容自动添加到对应的段后。

同样基于这个了解，如果finally段内如果有return关键字的话，异常已经被捕获，在再次抛出之前，return导致了Frame的出栈，从而导致后面的(athrow)没有执行，JVM的异常状态神奇的消失了。所以在代码实现上面，一定要避免这种有违异常约定的写法。
（现在java编译器已经对此种语法给出警告：(finally block does not complete normally)