在实际的j2ee项目中，系统内部难免会出现一些异常，如果把异常放任不管直接打印到浏览器可能会让用户感觉莫名其妙，也有可能让某些用户找到破解系统的方法。

　　出来工作一年时间了，我也大概对异常处理有了一些了解，在这呢小弟简单介绍下个人对异常处理的见解，抛砖引玉，希望各位大神提出宝贵的意见和建议。

　　拿spring+struts2+hibernate项目说明：通常一个页面请求到后台以后，首先是到action（也是所谓mvc的controller），在action层会调用业务逻辑service，servce层会调用持久层dao获取数据。后执行结果会汇总到action，然后通过action控制转发到指定页面，执行流程如下图所示：

　　而这三层其实都有可能发生异常，比如dao层可能会有SQLException，service可能会有NullPointException，action可能会有IOException，一但发生异常并且程序员未做处理，那么该层不会再往下执行，而是向调用自己的方法抛出异常，如果dao、service、action层都未处理异常的话，异常信息会抛到服务器，然后服务器会把异常直接打印到页面，结果会如下图所示：

　　其实这种错误对于客户来说毫无意义，因为他们通常是看不懂这是什么意思的。

　　刚学java的时候，我们处理异常通常两种方法：①直接throws，放任不管；②写try...catch，在catch块中不作任何操作，或者仅仅printStackTrace()把异常打印到控制台。第一种方法后造了上图的结果；而第二种方法更杯具：页面不报错，但是也不执行用户的请求，简单的说，其实这是bug（委婉点：通常是这样）！

　　那么发生异常到底应该怎么办呢？我想在大家对java异常有一定了解以后，会知道：异常应该在action控制转发之前尽量处理，同时记录log日志，然后在页面以友好的错误提示告诉用户出错了。大家看下面的代码：

 

//创建日志对象
Log log = LogFactory.getLog(this.getClass());
 
//action层执行数据添加操作
public String save(){
   try{
         //调用service的save方法
         service.save(obj);
   }catch(Exception e){
         log.error(...);   //记录log日志
      return "error"; 到指定error页面
   }
   return "success";
}

 　　如果按照上面的方式处理异常以后，我们用户后看到的页面可能会是下面这种形式（我想这种错误提示应该稍微友好点了吧）：

　　然后我们回到刚才处理异常的地方，如果大家积累了一些项目经验以后会发现使用上面那种处理异常的方式可能还不够灵活：

　　①因为spring把大多数非运行时异常都转换成运行时异常（RuntimeException）后导致程序员根本不知道什么地方应该进行try...catch操作

　　②每个方法都重复写try...catch，而且catch块内的代码都很相似，这明显做了很多重复工作而且还很容易出错，同时也加大了单元测试的用例数（项目经理通常喜欢根据代码行来估算UT case）

　　③发生异常有很多种情况：可能有数据库增删改查错误，可能是文件读写错误，等等。用户觉得每次发生异常都是“访问过程中产生错误，请重试”的提示完全不能说明错误情况，他们希望让异常信息更详尽些，比如：在执行数据删除时发生错误，这样他们可以更准确地给维护人员提供bug信息。