在Java语言中
如果一个方法有可能导致Checked异常抛出，则该方法要么需要捕获该异常并妥善处理，要么必须把该异常列在自己的throws子句中，否则无法通过编译。
请注意，Java虚拟机规范并没有这个规定，这只是Java语言的语法规则。
异常可以由Java虚拟机抛出，也可以由Java代码抛出。
athrow 指令
比如这个↓
void tryItOut() {
throw new TestExc();
}
throw new TestExc();这样的代码 会把这个异常对象入栈,然后执行athrow
athrow执行过程:
拿到栈顶的异常对象,
从本帧开始,一个个去找帧对应方法的异常处理表, 标准是 :
- 当前pc在异常表里面指定范围
[start_pc,end_pc]里面(异常表记录try块的起止指令), - 异常对象的类型属于
catch_type
handler_pc,指向了catch块开始的pc位置
如果找到了:
- 操作数栈清空 operandStack.clear();
- 异常对象引用推入栈顶 operandStack.push(exObject);
- 跳转到异常处理代码 frame.setNextPC(handlerPC);
这帧如果不是: 则把frame弹出，继续遍历。
帧都出完,都没找到匹配的方法异常处理表项, 说明根本没有对应的catch块存在,
只好打印出Java虚拟机栈信息,先打印出 异常类名:异常信息, 接着是异常对象的extra里面的信息,
异常对象都是Throwable的子类, Throwable构造方法会调用本地方法把extra填上报错信息↓
fillInStackTrace
异常构造函数都调用了超类java.lang.Throwable的构造函数。Throwable
的构造函数又调用了fillInStackTrace（）方法↓记录Java虚拟机栈信息
// java.lang.Throwable
public synchronized Throwable fillInStackTrace() {
if (stackTrace != null ||backtrace != null /* Out of protocol state */ ) {
//同名重载本地方法
fillInStackTrace(0);
stackTrace = UNASSIGNED_STACK;
}
return this;
}
//本地方法
private native Throwable fillInStackTrace(int dummy);
本地方法fillInStackTrace往extra里面放异常信息:
除了JvmStack顶的2帧 调用fillInStackTrace的 ,和异常对象和其祖先类的构造方法的帧, 这些异常记录帧以外的frame, 每个都给生成一个对应的StackTraceElement,由近及远 放入现在正在生成的异常对象的extra里面
这样来用frame->StackTraceElement:
-
clazz.getSourceFile(): frame的方法的类 可能有个源文件名属性
class属性 - clazz.getJavaName(): 类名 /变.
- method.getName():方法名
-
method.getLineNumber(frame.getNextPC() - 1)) 异常抛出的代码行号,方法可能有个行号属性, 也是Code属性的子属性
记录这个pc开始是在源码的第几行
10.3 异常处理表
是try catch 的体现
方法的异常处理表exception_table 和code[]字节码一样 也在method的Code属性里面,和 code[] ,max_stack,max_locals 并列
Code_attribute {
//属性都有的
u2 attribute_name_index;
u4 attribute_length;
u2 max_stack;
u2 max_locals;
//字节码
u4 code_length;
u1 code[code_length];
//方法的异常处理表
u2 exception_table_length;
{
u2 start_pc;
u2 end_pc;
u2 handler_pc;
u2 catch_type;
} exception_table[exception_table_length];
//子属性
u2 attributes_count;
attribute_info attributes[attributes_count];
}
方法的Code属性里面和code[]字节码并列的有一个异常处理表exception_table
catchOne()方法为例↓
void catchOne() {
try {
tryItOut();
} catch (TestExc e) {
handleExc(e);
}
}
void tryItOut() {
throw new TestExc();
}
void handleExc(RuntimeException exc) {
}
catchOne（）的code[] :
00: aload_0push(localVal[0]就是this) ←start_pc: 0 try的开始
01: invokevirtual #4- >jvmgo/book/ch10/JvrnsExample.tryltOuttryltOut()
04: _goto 13去13 ←end_pc: 4 try的结束
07: astore_1localVal[1]=pop ← catch这开始
08: aload_0push(this)
09: aload_1push(异常)
10: invokevirtual #5->jvmgo/book/ch10/JvmsExample.handleExc handleExc(e)
13: return
catchOne（）的exception_table 异常处理表 这里只有一个异常 只有一项
start_pc: 0try{}代码块开始
end_pc: 4try{}代码块结束
handler_pc: 7负责异常处理的catch代码开始
catch_type: #2->jvmgo/book/ch10/JvmsExamp|e$TestExc索引，通过它可以从运行时常量池中查到一个类符号引用，解析后的类是个异常类
流程是:
在01时tryltOut()抛出了异常, 开始找由近及远查看fram栈帧的异常处理表, 看能不能处理, tryltOut方法的异常处理表是空的 不能处理, 所以tryltOut出栈
接着检查catchOne的异常处理表的每项,第一项就对上了:
- 发生异常的pc在 catchOne里面是01,
在
start_pc: 0try{}代码块开始
end_pc: 4try{}代码块结束的范围里面, - 抛出的异常对象 和TestExc类型对上
说明就该在catchOne里面处理, 这个对上的异常处理表项handler_pc: 7说明catch在 07开始, 跳转到pc:07 执行就行了, 就是执行下面这些:
07: astore_1localVal[1]=pop ← catch这开始
08: aload_0push(this)
09: aload_1push(异常)
10: invokevirtual #5->jvmgo/book/ch10/JvmsExample.handleExc handleExc(e)
13: return
