eclipse查看异常打印信息和借此debug的方法

 

1).将模块代码放入junit测试方法中,发动junit.出现异常信息.junit的异常栈中往往看不到主方法,这是因为eclipse先发动自带的junit类中的主方法,然后交给org.junit中的测试类.如果在框架下debug,junit会先初始化框架.因为上述原因,导致junit的栈信息中的...more的行数往往和显示的不符,但这不是重点,只需右击copy trace,然后粘贴就能看的trace的全貌,大部分情况下隐藏的trace都不是问题所在.异常栈的全径即创建该异常的线程启动点(一般是一个main方法)到该异常发生之时的所经历的所有方法栈.报告的位置就是new expection()的位置,从信息中无法确定throw和catch的位置,但这并不重要.为什么需要junit来进行测试而不是主方法.因为采用IOC思想开发的Web程序往往不允许程序员创建主方法,而且junit能帮助完成初始化代码.用junit是个明智之选.

2),对于抛出自定义具体异常而且报告原因和根源一致的bug,只需要查看最后一层caused by的信息就可解决问题,甚至有时候只需要查看top-level的异常就能解决,这些算不上挑战.

3).最难的问题是对于exception报告了一个unspecific的runtime异常,比如一个nullpointerexception,这种不明确的异常必须通过严格代码跟踪找到数据错误的点,代码跟踪的两个必须条件:1,所有的class文件必须是携带debug信息的(最重要的两个信息是源代码文件名和行号).2所有的类和其对应的源码必须是同一版本的(即所有的class文件都是可以由对应同名的.java文件编译得到).第一个方面遇到的问题一般是JDK中的class文件为了降低体积使用了:none参数编译,导致debug信息丢失,解决的办法可以寻找带debug信息的版本,或者重新编译源码.对于找不到源码的jar包可以用反编译工具反编译或者干脆换个能找到源码的版本?(这样做有潜在的兼容性风险).在看到trace信息后,依据栈中出现的方法所在类,添加对应对应源码.然后在各个栈的入口处添加断点,单步跟踪,从断点所在方法入口step into,观察过程中的变量变化,最后找到异常的位置.但即便如此也只能定位问题所在,如果不是对程序流程经历的各个模块都十分熟悉,即便找到了数据错误的位置,也很难解决问题.这种解决bug的思路无疑是一种低效率,高时间代价的方式,除非一切可以利用的间接方法都失效了而且编程者本人的基本功很扎实,否则不推荐这种方式.

注:关于java文件中的行号和class文件中的行号,往往冗长的一条java代码(可能占据好几行)会生成很多字节码指令,所以class反汇编的文件常常多"行"(PC步进值)对应一个java源文件的行号(此条代码的初始行).在debug的时候单步指令将反复在一行源码上执行,执行的顺序是先将传参入栈(形参初始化),执行方法体,最后返回.循环语句有类似的情况,最后return由loop取代.大部分情况下在源码上控制单步是清晰,如果遇到了十分罕见情况,可以查看反汇编字节码文件.