CAE开发日志（5）：日志与异常处理机制

1、CAE的日志支持

一开始我是想使用java原生的日志（java.util.log）来实现CAE的日志，但是发现java原生的log还是太弱了，灵活性也不足，最重要的是配置写入log文件时的配置查了网上的教程还是没有作用。

后来CAE的日志就改用了log4j来实现，目前配置的log4j一共有两种输出方式，一种是INFO级别以上的日志将会输出到控制台，另一种是WARN级别的日志将会输出到错误文件中。log4j其实也比较坑，网上的教程中有说到可以通过web.xml配置让spring注入一个webroot.key变量，这个变量可以自动获取当前项目在机器上的部署路径，这样log4j.properties里面就不用配置绝对路径了，移植性也更好。我配了，从控制台上也看到了webroot.key已经成功注入到系统中，log4j.properties里面也的确使用了${webroot.key}的引用，可是根本就没注入进去！所以现在的日志路径依然是绝对路径，这个以后可能需要再解决。

2、CAE的异常处理机制

目前CAE是一个业务主要集中在dao层的应用，所以controller层和service层并没有做过多的异常处理，目前一般是针对dao层的异常来进行处理，每个dao层方法的主逻辑一般都会包裹在一个try-catch块中，try块是正常的逻辑，catch块则是出异常的逻辑，一般try块中抛了一个没有预料到的异常会把这个异常链写入到文件中，主要形式的代码框架如下：

try{//正常的业务逻辑} catch(knownException ex){//可预测、已知的异常所做的逻辑//例如“当前歌曲不存在call表”时就会抛出EmptyResultDataAccessException，但这个异常是可预料的、可接受的，所以只要普通info一下就好logger.info();ex.printStackTrace();return null;} catch(Exception ex){//未知的异常，写入错误日志文件Util.logStackTrace(logger, ex.getStackTrace());ex.printStackTrace();return null;}

可以看到，异常这里分为了两类，一类是业务允许范围内的异常，这种异常是可预测、可预知、对系统无害无风险的异常，一般只要info一下，打到控制台即可；另一种是预想之外的异常，对于这种异常，因为有检测到bug甚至是危害系统的风险，所以需要把整个异常链都记录下来，Util.logStackTrack()方法是我封装的一个方法，用于把异常链通过log4j写入文件。

3、日志级别及含义

一般日志系统都会把输出的日志分为多个等级，例如log4j输出的信息严重性从低到高分别是：debug、info、warn、error、fatal（还有其他的一些特殊级别，这里没有用到就不列出了），目前CAE使用到的级别有info、warn、error、fatal，它们分别对应的使用场景是：

info：普通的信息

warn：出现了异常，但是这个异常并不会太影响真正的逻辑，例如每次点进call表详细页对应的歌曲点击量会+1，如果此时这个+1的操作失败了其实并不会太影响后续的操作甚至是系统本身，所以使用warn来记录，这也是会写入文件的

error：出现了异常，这个异常是开发时没有预料到的，一般是程序的bug出现的地方，它用于dao层方法的catch(Exception ex)块中。

fatal：最严重的的错误，这种情况就是在error的基础上，再加上出现异常的类中没有logger对象的情况，这就表示出异常的这个类在开发时“根本不会想到这个类会抛异常”的情况，此时就要使用AOP切面自身的logger来记录这个错误，关于AOP与CAE的日志系统的联系在下一节会提到。

4、AOP——最后一道异常记录防线

目前所有的dao层都有自己的logger，在打印error级别的日志时，dao层并不会自己打印，而是把logger对象和异常对象传给Util工具类，在Util.logStackTrace()方法中统一打印，如果出现了一些没有传给logStackTrace()方法的异常（目前目测是没有的），那么我的AOP异常拦截会把这种最诡异的异常情况以fatal的级别记录下来。