Java异常处理设计（二）

考虑对JDK的底层堆栈信息进行处理，一种是重写JDK的Throwable，另一种是在原错误堆栈信息上进行“二次加工”。目前这两种方式我都实现了，效果非常好。

这篇文章主要记录对错误堆栈进行“二次加工”的实现过程。

从大量的实际错误日志分析出发：

首先，追根溯源，找到错误是从哪个地方new出来的。

例如
com.jfinal.plugin.activerecord.ActiveRecordException: java.lang.ClassCastException: com.alibaba.druid.sql.visitor.SQLEvalVisitorImpl cannot be cast to com.alibaba.druid.sql.dialect.sqlserver.visitor.SQLServerASTVisitor
 at com.jfinal.plugin.activerecord.Db.paginate(Db.java:554)
 at com.jfinal.plugin.activerecord.Db.paginate(Db.java:593)
 at com.simple.sqpt.services.FWCXService.doGetHouseInfo(FWCXService.java:172)

那么是在Db.paginate(Db.java:554)这一行new出来的，后面有：
Caused by: java.lang.ClassCastException: com.alibaba.druid.sql.visitor.SQLEvalVisitorImpl cannot be cast to com.alibaba.druid.sql.dialect.sqlserver.visitor.SQLServerASTVisitor
 at com.alibaba.druid.sql.dialect.sqlserver.ast.SQLServerSelectQueryBlock.accept0(SQLServerSelectQueryBlock.java:39)
 at com.alibaba.druid.sql.ast.SQLObjectImpl.accept(SQLObjectImpl.java:40)
说明这个new出来的错误，是包裹了另外一个错误，可能是有new ActiveRecordException(e);然后这个e是一个ClassCastException类型错误
因为只有一个Caused by，可以肯定，这个(ClassCastException) e 是源头，是从：
SQLServerSelectQueryBlock.accept0(SQLServerSelectQueryBlock.java:39)这里new出来的。

应用的栈信息可能夹在中间，比如：

org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.ibm.websphere.ce.cm.StaleConnectionException: The Network Adapter could not establish the connectionDSRA0010E: SQL State = 61000, Error Code = 20
  at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:82)
  at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:577)
  at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:641)
  at org.springframework.jdbc.core.JdbcTemplate.queryForInt(JdbcTemplate.java:759)
  at com.proj.webc.persist.framework.BaseDAO.queryForCount(BaseDAO.java:142)
  at com.proj.webc.persist.office.dao.OfficeDAO.queryBackUsersCountByCondition(OfficeDAO.java:734)
  at com.proj.webc.logic.office.OfficeManagerImpl.queryCountOfficeByCondition(OfficeManagerImpl.java:79)
  at com.proj.webc.present.orderquery.action.FrontOrderQueryAction.doAction(FrontOrderQueryAction.java:118)
  at com.proj.webc.framework.BaseAction.execute(BaseAction.java:205)
  at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Method.java:600)
  at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:450)
  at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)

像这种，其实我们只能操纵应用之前的错误信息，应用之后的，超出了我们的管理范围。 比如上面这个例子，在com.proj.**之前的org.springframework.**是我们可以管理的， 但是后面的sun.reflect.**，java.lang.**，com.opensymphony.**都超出了应用的可视范围。 （除非从源头控制，比如com.opensymphony.**的源码，最上层，应该是webContainer，例如websphere下，最外层的栈信息都是com.ibm.**开头）

分析上面的错误信息，我们可以操作的最外层，是 com.proj.webc.framework.BaseAction.execute(BaseAction.java) 我们可以在这个地方做工作，把它管辖之下的错误信息进行整理，例如可以把 org.springframework.**这种信息都过滤掉。

如果是用log工具，我们就有控制权。

综上分析，对于最上层，紧跟着错误信息的地方，只需要追溯到错误new出来之前的前几个轨迹即可。 一般来说，只需要跟踪和new出来错误的那个类在同一个api包之中的，比如上面这个例子， 只需要跟踪到第二行 com.jfinal.plugin.activerecord.Db.paginate(Db.java:593)即可。

对于Caused by，是非常核心的错误出处，一般是在应用之中的，可采取和上面一样的处理方式，如果是调用第三方api抛出的错误，如上面那个例子。 其实捕获栈信息的意义不是很大，但是也可以少量捕捉一些，比如一前一尾。但是尾巴不好判断，所以考虑到性能，只捕捉前面2行就够意思了。后面的话 要逐行判断，如果是本应用的类，则捕捉。

捕捉到最后，是三个点：  ... 39 more 这样，Caused by就处理完成了。如果后面还有Caused by，也用该方法继续捕捉。

综上，其实就一个方法： 检测非\tat开头的字符串，记录其信息。（可设定长度大小，比如小于1000）

对于\tat开头的字符串，判断是否为本应用+特定api的前缀，是则保留。

特殊处理： 保留紧跟着非\tat开头的字符串的2行栈信息，

保留出现本应用+特定api前缀那一行的前3行信息。

算法复杂度，假设有100行，一行比较30次char（用startWith），总共for循环100次，每次比较一个startWith，

每次循环假设还做一个5个if的判断，那么一共比较的次数为500+3000=3500，对CPU来说，应该不成问题。