业务ｆｒａｍｅｗｏｒｋ中Ｅｘｃｅｐｔｉｏｎ的设计与ｌｏｇ的纪录方式

 一，Exception的设计
１、uncheck Exception的使用
    服务器的framework中，所有的Exception都有框架来处理，业务不需要处理Exception。所以服务器端全部使用uncheck Exceptino。服务器端的uncheck Exception分为三种：

• SystemException
• DBException
• BusinessException

   1）、SystemException：当系统配置，文件操作等异常发现的时候抛出
   2）、DBException：当DB异常发生的时候抛出，并将SQLException中的errorCode解析为易于理解的消息
   3）、BusinessException：当业务异常发生时抛出。
       BusinessException分为两种模式，默认为普通模式，异常抛出后，客户端框架会自动报出错误消息，另一种为逃避模式，异常抛出后，客户端框架不会报出错误消息，转化后向上抛出业务程序。
2、check Exception的使用
    当服务器端的处理发生错误时，客户端的业务程序必须要处理。所以当客户端将服务器端返回的Uncheck Exception转换为Check Exception

• FrameBusinessException

    所以异常到客户端后，都转换为FrameBusinessException，不同的异常对应不同的异常类型，有：

• SYSTEMERROR
• DBERROR
• BUSINESSERROR
• BUSINESSESCAPE
• REMOTINGERROR

其中BUSINESSESCAPE不报错误消息，BUSINESSERROR报自己异常的错误消息。其他的异常统一报“Action Name处理时发生错误。（理由：{2}）”，理由中填入异常的消息，REMOTINGERROR填入“网络异常”。如：“用户管理画面加载处理是发生错误。（理由：DB连接异常）”。

三、改进期望-InterruptException
    在现在的系统中存在一种特殊的情况：服务器处理的过程中会报出一个警告通知客户端，等客户端确认以后继续服务器端的处理。
    现在系统中碰到这种情况就需要手工保存当前处理的状态，传回客户端，等确认后再传回服务器端手工服务状态继续处理。这种处理经常导致应该保存的数据没有保存，导致再回来继续处理的时候已经不能完全恢复当时的状态，导致系统异常。
    改善建议：加入一种中断异常，当系统碰到上述情况时抛出。由框架保存当前Action的状态，等客户端确认后再返回服务器时由服务器端框架恢复当时的处理状态。

四、log纪录
    当捕获异常后，如果要向上继续抛出异常就将异常信息保存到新异常中；如果要继续处理就应该在ERROR或WARN级别打印异常的详细信息。