J2EE项目中异常的设计与处理

异常设计

0.J2EE中的异常设计
             3层结构 Dao，Service，Controller
   异常处理原则：
              应该在Controller控制转发之前尽量处理，同时记录log日志，然后在页面以友好的错误提示告诉用户出错了
   eg：
       //创建日志对象
       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";
       }

   1.Dao层异常
              可预测异常        抛给Service层处理，有些包含了很有用的信息，eg：用户名重复的异常
              不可预测异常      自己封装起来，然后重新包装自定义的异常，抛给Service处理
   2.Service层异常
              类似DAO层异常处理
   3.Controller层处理异常
              1.Controller中可以处理任何来自底层的异常，如果是有用的信息，我们可以抛给用户，以便提示用户
              2.定义统一异常处理(Spring方式或Struts2的xml方式)，也可以分类处理异常     ---  最重要，减少手动编程，灵活处理
   4.框架本身异常或其他未知异常
              在web.xml中配置便签，由服务容器来处理并定向到指定的页面
              配置404、400、500等异常的页面用户展示

      1.自定义异常  --- 主要用于包装异常
         eg：
           public class BaseException extends Exception {

               private static final long serialVersionUID = -4368304810297242836L;

               private String errorCode;

               private Exception exception;

               private String errorMessage;

               /**
                * @param e which cause exception
                * @param errorCode which is defined in @ErrorCodeUtil
                */
               public BaseException(Exception e, String errorCode) {
                  this.errorCode = errorCode;
                  this.exception = e;
               }

               public BaseException(Exception e) {
                  this.exception = e;
               }

               public BaseException(String errorCode) {
                  this.errorCode = errorCode;
               }

               public BaseException(String errorCode, String errorMessage) {
                  this.errorCode = errorCode;
                  this.errorMessage = errorMessage;
               }

               public BaseException(Exception e, String errorCode, String errorMessage) {
                  this.exception = e;
                  this.errorCode = errorCode;
                  this.errorMessage = errorMessage;
               }

               /**
                * @description errorCode which is defined in @ErrorCodeUtil
                * @author Jay He
                * @time Sep 28, 2015 10:34:15 AM
                * @return String
                */
               public String getErrorCode() {
                  return errorCode;
               }

               public Exception getException() {
                  return exception;
               }

               public String getErrorMessage() {
                   return errorMessage;
               }

           }

      2.DAO层异常，继承自BaseException
         eg：
           public class DataException extends BaseException{

               private static final long serialVersionUID = 1L;

               public DataException(Exception e, String errorcode) {
                   super(e, errorcode);
               }

               public DataException(String errorcode) {
                   super(errorcode);
               }

               public DataException(String errorCode, String errorMessage) {
                  super(errorCode, errorMessage);
               }

               public DataException(Exception e, String errorCode, String errorMessage) {
                  super(e,errorCode, errorMessage);
               }
           }

      3.Service层异常，继承BaseException
         eg：
           public class ServiceException extends BaseException{

           private static final long serialVersionUID = 1L;

           public ServiceException(Exception e, String errorcode) {
            super(e, errorcode);
           }

           public ServiceException(String errorcode) {
            super(errorcode);
           }

            public ServiceException(String errorCode, String errorMessage) {
                super(errorCode, errorMessage);
            }

            public ServiceException(Exception e, String errorCode, String errorMessage) {
                super(e,errorCode, errorMessage);
            }
           }
      4.其他异常   ---  根据实际需求自定义的异常
          1.权限异常
             eg：
               public class AuthorityException extends BaseException{

                   private static final long serialVersionUID = -4529873012715523511L;

                   public AuthorityException(Exception e, String errorcode) {
                       super(e, errorcode);
                   }

                   public AuthorityException(String errorcode) {
                       super(errorcode);
                   }

                   public AuthorityException(String errorCode, String errorMessage) {
                      super(errorCode, errorMessage);
                   }

                   public AuthorityException(Exception e, String errorCode, String errorMessage) {
                      super(e,errorCode, errorMessage);
                   }
               }

          2.其他自定义异常
             eg:
               public class ParameterException extends BaseException{

                   private static final long serialVersionUID = -5488824506686142281L;

                   public ParameterException(Exception e, String errorcode) {
                       super(e, errorcode);
                   }

                   public ParameterException(String errorcode) {
                       super(errorcode);
                   }

                   public ParameterException(String errorCode, String errorMessage) {
                      super(errorCode, errorMessage);
                   }

                   public ParameterException(Exception e, String errorCode, String errorMessage) {
                      super(e,errorCode, errorMessage);
                   }
               }

1.异常处理
    1.Dao与Service异常处理
        接口：
            eg:
               SigProfile saveSigProfile(SigProfile sigProfile) throws Exception;
        实现：
            eg:
               public SigProfile saveSigProfile(SigProfile sigProfile) throws Exception {
               try {
                  // 逻辑处理代码
               } catch (Exception e) {
               throw new ServiceException(errorMsg + e.getMessage());
               }
               }
    2.Controller层异常处理
            1.统一异常处理
            2.特定异常处理
    3.异常页面
            web.xml中配置常见的400、403、404、500等页面跳转

    对异常进行分离出来，并进行封装输出
     eg:
       public void doStuff()
       {
         try
         {
           //do something
         }
         catch (FileNotFoundException e)
         {
           log.info("文件未找到!文件为:xxx");
         }
         catch (SecurityException e)
         {
           log.error("无权访问,原因:xxx");
           e.printStackTrace();
         }
       }

2.整体异常处理机制

在实际的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信息。

 

如何解决上面的问题呢？我是这样做的：JDK异常或自定义异常+异常拦截器

struts2拦截器的作用在网上有很多资料，在此不再赘述，我的异常拦截器原理如下图所示：

 首先我的action类、service类和dao类如果有必要捕获异常，我都会try...catch，catch块内不记录log，通常是抛出一个新异常，并且注明错误信息：

 //action层执行数据添加操作
 public String save(){
    try{
          //调用service的save方法
          service.save(obj);
    }catch(Exception e){
       //你问我为什么抛出Runtime异常？因为我懒得在方法后写throws  xx
       throw new RuntimeException("添加数据时发生错误！",e);
   }
    return "success";
 }

 

 

然后在异常拦截器对异常进行处理，看下面的代码：

 public String intercept(ActionInvocation actioninvocation) {

         String result = null; // Action的返回值
         try {
             // 运行被拦截的Action,期间如果发生异常会被catch住
             result = actioninvocation.invoke();
             return result;
         } catch (Exception e) {
             /**
              * 处理异常
              */
             String errorMsg = "未知错误！";
             //通过instanceof判断到底是什么异常类型
             if (e instanceof BaseException) {
                 BaseException be = (BaseException) e;
                 be.printStackTrace(); //开发时打印异常信息，方便调试
                 if(be.getMessage()!=null||Constants.BLANK.equals(be.getMessage().trim())){
                     //获得错误信息
                     errorMsg = be.getMessage().trim();
                 }
             } else if(e instanceof RuntimeException){
                 //未知的运行时异常
                 RuntimeException re = (RuntimeException)e;
                 re.printStackTrace();
             } else{
                 //未知的严重异常
                 e.printStackTrace();
             }
             //把自定义错误信息
             HttpServletRequest request = (HttpServletRequest) actioninvocation
                     .getInvocationContext().get(StrutsStatics.HTTP_REQUEST);

             /**
              * 发送错误消息到页面
              */
             request.setAttribute("errorMsg", errorMsg);

             /**
              * log4j记录日志
              */
             Log log = LogFactory
                     .getLog(actioninvocation.getAction().getClass());
             if (e.getCause() != null){
                 log.error(errorMsg, e);
             }else{
                 log.error(errorMsg, e);
             }

             return "error";
         }// ...end of catch
     }

 需要注意的是:在使用instanceof判断异常类型的时候一定要从子到父依次找，比如BaseException继承与RuntimeException，则必须首先判断是否是BaseException再判断是否是RuntimeException。

 

 

最后在error JSP页面显示具体的错误消息即可：

 if test="%{#request.errorMsg==null}">
     对不起，系统发生了未知的错误
 if>
 else>
     ${requestScope.errorMsg}
 else>

 

以上方式可以拦截后台代码所有的异常，但如果出现数据库连接异常时不能被捕获的，大家可以使用struts2的全局异常处理机制来处理：

     "error" >/Web/common/page/error.jsp



     "error" exception="java.lang.Exception">

 

上面这是一个很简单的异常拦截器，大家可以使用自定义异常，那样会更灵活一些。

 

以上异常拦截器可以使用其它很多技术替换：比如spring aop，servlet filter等，根据项目实际情况处理。

 

【补充】ajax也可以进行拦截，但是因为ajax属于异步操作，action通过response形式直接把数据返回给ajax回调函数，如果发生异常，ajax是不会执行页面跳转的，所以必须把错误信息返回给回调函数，我针对json数据的ajax是这样做的：

 /**
  * 读取文件，获取对应错误消息
  */
 HttpServletResponse response = (HttpServletResponse)actioninvocation.getInvocationContext().get(StrutsStatics.HTTP_RESPONSE);
 response.setCharacterEncoding(Constants.ENCODING_UTF8);
 /**
  * 发送错误消息到页面
  */
 PrintWriter out;
 try {
     out = response.getWriter();
     Message msg = new Message(errorMsg);
     //把异常信息转换成json格式返回给前台
     out.print(JSONObject.fromObject(msg).toString());
 } catch (IOException e1) {
     throw e;
 }

 

3.使用Spring MVC统一异常处理

1 描述 
在J2EE项目的开发中，不管是对底层的数据库操作过程，还是业务层的处理过程，还是控制层的处理过程，都不可避免会遇到各种可预知的、不可预知的异常需要处理。每个过程都单独处理异常，系统的代码耦合度高，工作量大且不好统一，维护的工作量也很大。 
那么，能不能将所有类型的异常处理从各处理过程解耦出来，这样既保证了相关处理过程的功能较单一，也实现了异常信息的统一处理和维护？答案是肯定的。下面将介绍使用Spring MVC统一处理异常的解决和实现过程。 

2 分析 
Spring MVC处理异常有3种方式： 
（1）使用Spring MVC提供的简单异常处理器SimpleMappingExceptionResolver； 
（2）实现Spring的异常处理接口HandlerExceptionResolver 自定义自己的异常处理器； 
（3）使用@ExceptionHandler注解实现异常处理； 

3 实战 
3.1 引言 
为了验证Spring MVC的3种异常处理方式的实际效果，我们需要开发一个测试项目，从Dao层、Service层、Controller层分别抛出不同的异常，然后分别集成3种方式进行异常处理，从而比较3种方式的优缺点。 

3.2 实战项目 
3.2.1 项目结构 
 

3.2.2 Dao层代码 

 @Repository("testDao")
 public class TestDao {
     public void exception(Integer id) throws Exception {
         switch(id) {
         case 1:
             throw new BusinessException("12", "dao12");
         case 2:
             throw new BusinessException("22", "dao22");
         case 3:
             throw new BusinessException("32", "dao32");
         case 4:
             throw new BusinessException("42", "dao42");
         case 5:
             throw new BusinessException("52", "dao52");
         default:
             throw new ParameterException("Dao Parameter Error");
         }
     }
 }

3.2.3 Service层代码  

 public interface TestService {
     public void exception(Integer id) throws Exception;

     public void dao(Integer id) throws Exception;
 }

 @Service("testService")
 public class TestServiceImpl implements TestService {
     @Resource
     private TestDao testDao;

     public void exception(Integer id) throws Exception {
         switch(id) {
         case 1:
             throw new BusinessException("11", "service11");
         case 2:
             throw new BusinessException("21", "service21");
         case 3:
             throw new BusinessException("31", "service31");
         case 4:
             throw new BusinessException("41", "service41");
         case 5:
             throw new BusinessException("51", "service51");
         default:
             throw new ParameterException("Service Parameter Error");
         }
     }

     @Override
     public void dao(Integer id) throws Exception {
         testDao.exception(id);
     }
 }

3.2.4 Controller层代码  

 @Controller
 public class TestController {
     @Resource
     private TestService testService;

     @RequestMapping(value = "/controller.do", method = RequestMethod.GET)
     public void controller(HttpServletResponse response, Integer id) throws Exception {
         switch(id) {
         case 1:
             throw new BusinessException("10", "controller10");
         case 2:
             throw new BusinessException("20", "controller20");
         case 3:
             throw new BusinessException("30", "controller30");
         case 4:
             throw new BusinessException("40", "controller40");
         case 5:
             throw new BusinessException("50", "controller50");
         default:
             throw new ParameterException("Controller Parameter Error");
         }
     }

     @RequestMapping(value = "/service.do", method = RequestMethod.GET)
     public void service(HttpServletResponse response, Integer id) throws Exception {
         testService.exception(id);
     }

     @RequestMapping(value = "/dao.do", method = RequestMethod.GET)
     public void dao(HttpServletResponse response, Integer id) throws Exception {
         testService.dao(id);
     }
 }

3.2.5 JSP页面代码  

 <%@ page contentType="text/html; charset=UTF-8"%>


 Maven Demo


 所有的演示例子
 [url=./dao.do?id=1]Dao正常错误[/url]
 [url=./dao.do?id=10]Dao参数错误[/url]
 [url=./dao.do?id=]Dao未知错误[/url]


 [url=./service.do?id=1]Service正常错误[/url]
 [url=./service.do?id=10]Service参数错误[/url]
 [url=./service.do?id=]Service未知错误[/url]


 [url=./controller.do?id=1]Controller正常错误[/url]
 [url=./controller.do?id=10]Controller参数错误[/url]
 [url=./controller.do?id=]Controller未知错误[/url]


 [url=./404.do?id=1]404错误[/url]

3.3 集成异常处理  
3.3.1 使用SimpleMappingExceptionResolver实现异常处理  
1、在Spring的配置文件applicationContext.xml中增加以下内容： 

 <bean class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">

     <property name="defaultErrorView" value="error">property>

     <property name="exceptionAttribute" value="ex">property>

     <property name="exceptionMappings">
         <props>
             <prop key="cn.basttg.core.exception.BusinessException">error-businessprop>
             <prop key="cn.basttg.core.exception.ParameterException">error-parameterprop>


         props>
     property>
 bean>

2、启动测试项目，经验证，Dao层、Service层、Controller层抛出的异常（业务异常BusinessException、参数异常ParameterException和其它的异常Exception）都能准确显示定义的异常处理页面，达到了统一异常处理的目标。 

3、从上面的集成过程可知，使用SimpleMappingExceptionResolver进行异常处理，具有集成简单、有良好的扩展性、对已有代码没有入侵性等优点，但该方法仅能获取到异常信息，若在出现异常时，对需要获取除异常以外的数据的情况不适用。 

3.3.2 实现HandlerExceptionResolver 接口自定义异常处理器  
1、增加HandlerExceptionResolver 接口的实现类MyExceptionHandler，代码如下： 

 public class MyExceptionHandler implements HandlerExceptionResolver {

     public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler,
             Exception ex) {
         Map model = new HashMap();
         model.put("ex", ex);

         // 根据不同错误转向不同页面
         if(ex instanceof BusinessException) {
             return new ModelAndView("error-business", model);
         }else if(ex instanceof ParameterException) {
             return new ModelAndView("error-parameter", model);
         } else {
             return new ModelAndView("error", model);
         }
     }
 }

2、在Spring的配置文件applicationContext.xml中增加以下内容： 

 <bean id="exceptionHandler" class="cn.basttg.core.exception.MyExceptionHandler"/>

3、启动测试项目，经验证，Dao层、Service层、Controller层抛出的异常（业务异常BusinessException、参数异常ParameterException和其它的异常Exception）都能准确显示定义的异常处理页面，达到了统一异常处理的目标。 

4、从上面的集成过程可知，使用实现HandlerExceptionResolver接口的异常处理器进行异常处理，具有集成简单、有良好的扩展性、对已有代码没有入侵性等优点，同时，在异常处理时能获取导致出现异常的对象，有利于提供更详细的异常处理信息。 

3.3.3 使用@ExceptionHandler注解实现异常处理  
1、增加BaseController类，并在类中使用@ExceptionHandler注解声明异常处理，代码如下： 

 public class BaseController {
     /** 基于@ExceptionHandler异常处理 */
     @ExceptionHandler
     public String exp(HttpServletRequest request, Exception ex) {

         request.setAttribute("ex", ex);

         // 根据不同错误转向不同页面
         if(ex instanceof BusinessException) {
             return "error-business";
         }else if(ex instanceof ParameterException) {
             return "error-parameter";
         } else {
             return "error";
         }
     }
 }

2、修改代码，使所有需要异常处理的Controller都继承该类，如下所示，修改后的TestController类继承于BaseController： 

 public class TestController extends BaseController

3、启动测试项目，经验证，Dao层、Service层、Controller层抛出的异常（业务异常BusinessException、参数异常ParameterException和其它的异常Exception）都能准确显示定义的异常处理页面，达到了统一异常处理的目标。 

4、从上面的集成过程可知，使用@ExceptionHandler注解实现异常处理，具有集成简单、有扩展性好（只需要将要异常处理的Controller类继承于BaseController即可）、不需要附加Spring配置等优点，但该方法对已有代码存在入侵性（需要修改已有代码，使相关类继承于BaseController），在异常处理时不能获取除异常以外的数据。 

3.4 未捕获异常的处理  
对于Unchecked Exception而言，由于代码不强制捕获，往往被忽略，如果运行期产生了Unchecked Exception，而代码中又没有进行相应的捕获和处理，则我们可能不得不面对尴尬的404、500……等服务器内部错误提示页面。 
我们需要一个全面而有效的异常处理机制。目前大多数服务器也都支持在Web.xml中通过(Websphere/Weblogic)或者(Tomcat)节点配置特定异常情况的显示页面。修改web.xml文件，增加以下内容： 

 <error-page>
     <exception-type>java.lang.Throwableexception-type>
     <location>/500.jsplocation>
 error-page>
 <error-page>
     <error-code>500error-code>
     <location>/500.jsplocation>
 error-page>
 <error-page>
     <error-code>404error-code>
     <location>/404.jsplocation>
 error-page>

4 解决结果  
1、运行测试项目显示的首页，如下图所示： 


2、业务错误显示的页面，如下图所示： 


3、参数错误显示的页面，如下图所示： 


4、未知错误显示的页面，如下图所示： 


5、服务器内部错误页面，如下图所示： 


5 总结  
综合上述可知，Spring MVC集成异常处理3种方式都可以达到统一异常处理的目标。从3种方式的优缺点比较，若只需要简单的集成异常处理，推荐使用SimpleMappingExceptionResolver即可；若需要集成的异常处理能够更具个性化，提供给用户更详细的异常信息，推荐自定义实现HandlerExceptionResolver接口的方式；若不喜欢Spring配置文件或要实现“零配置”，且能接受对原有代码的适当入侵，则建议使用@ExceptionHandler注解方式。 

6 源代码  
源代码项目如下所示，为Maven项目，若需运行，请自行获取相关的依赖包。 
点击这里获取源代码  

7 参考资料  
[1] Spring MVC统一处理异常的方法 
http://hi.baidu.com/99999999hao/blog/item/25da70174bfbf642f919b8c3.html 
[2] SpringMVC 异常处理初探 
http://exceptioneye.iteye.com/blog/1306150 
[3] Spring3 MVC 深入研究 
http://elf8848.iteye.com/blog/875830 
[4] Spring MVC异常处理 
http://blog.csdn.net/rj042/article/details/7380442

4.编写高质量代码改善java程序的151个建议——[110-117]异常及Web项目中异常处理

摘要:

• 异常处理概述

学习内容:

• 建议110： 提倡异常封装
• 建议111： 采用异常链传递异常
• 建议112： 受检异常尽可能转化为非受检异常  
• 建议117： 多使用异常，把性能问题放一边

思考:

• java web 中的异常处理

 

何为异常处理?

异常处理，英文名为exceptional handling, 是代替日渐衰落的error code方法的新法，提供error code 所未能具体的优势。异常处理分离了接收和处理错误代码。这个功能理清了编程者的思绪，也帮助代码增强了可读性，方便了维护者的阅读和理解。

java语言中,异常处理可以确保程序的健壮性,提高系统的可用率.但是java api 提供的异常都是比较低级的,所以有了'提倡异常封装’

                                                                           

 

提倡异常封装

异常封装有三个优点:  1)提高系统的友好性   2)提高性能的可维护性   3)解决java异常机制自身的缺陷

 

• 提高系统的友好性

---

系统的友好性,就像系统和开发人员等握手与交流.好的系统对象,会展现出交流时候所需要的一切.因此,良好的友好性需要良好的代码告诉开发人员和用户.开发人员要找需要打印出堆栈信息.

                                                    

show the code:

public void doStuff() throws MyBussinessException
    {
        try
        {
            InputStream iStream = new FileInputStream("无效文件.txt");
        }
        catch (FileNotFoundException e)
        {
            e.printStackTrace();
            throw new MyBussinessException(e);//此处自定义一个MyBussinessException
        }
        
    }

::throw new MyBussinessException(e);

在这里,无效文件导致了两点:文件未找到和该业务出现问题.因此,在文件未找到之后我们可以继续根据需要告之其他异常.

 

• 提高性能的可维护性

---

如何提搞可维护性,大家不能一味的进行这样操作,就抛出Exception,这样会导致别人看你的代码完全check不到异常点.下面的代码是不可取的:

public void doStuff()
{
    try
    {
        //do something
    } catch (Exception e)
    {
        e.printStackTrace();
    }
}

 

正确的做法是对异常进行分类处理,并进行封装输出.

show the code:

public void doStuff()
{
    try
    {
        //do something
    }
    catch (FileNotFoundException e)
    {
        log.info("文件未找到!文件为:xxx");
    }
    catch (SecurityException e) 
    {
        log.error("无权访问,原因:xxx");
        e.printStackTrace();
    }
}

catch{}

catch{}

这样子,直接在代码层级上分析即可,代码异常在哪里抛出.维护人员看到这样的异常也会有了准确的判断.

 

• 解决java异常机制自身的缺陷

---

先抛出个问题:例如注册时,要对很多进行检验.像密码,用户名,邮箱…...这样情况下,我们必须要在一个注册方法里面抛出很多个异常.因此,正确的方法是封装异常,建立异常容器,一次性对某对象进行校验,然后返回所有异常.

show the code

异常容器:

import java.util.ArrayList;
import java.util.List;

public class MyException extends Exception
{
    //容纳所有异常
    private List causes = new ArrayList();
    //构造函数
    public MyException(Listextends Throwable> _causes)
    {
        causes.addAll(_causes);
    }
    //读取所有的异常
    public List getExceptions()
    {
        return causes;
    }
}

处理异常:

public static void doStuff() throws MyException
{
    List list = new ArrayList();
    //第一个逻辑片段
    try
    {
        //Do Something
    } 
    catch (Exception e)
    {
        list.add(e);
    }
    //第二个逻辑片段
    try
    {
        //Do Something two
    } 
    catch (Exception e)
    {
        list.add(e);
    }
    //检查是否有必要抛出异常
    if(list.size() > 0)
    {
        throw new MyException(list);
    }
}

 

采用异常链传递异常

我们做的JEE项目时候,一般会有三层的结构:持久层,逻辑层,展现层.异常也是如此的,当我们各个层之间传递异常,我们就需要先封装,然后传递.简要的就是采用异常传递异常:

 

show the code:

[摘自源码分析]

/**
 * 
 * 执行 SQL 查询。
 * 
 * @param isCallable    : 是否使用 CallableStatment 执行查询
 * @param sql            : 查询语句
 * @param params        : 查询参数
 * @return                  结果集
 * 
 */
protected List query(boolean isCallable, String sql, Object ... params)
{
    List result = new ArrayList();
    
    ResultSet rs = null;
    PreparedStatement pst = null;

    try
    {
        Connection conn = getSession();
        pst = JdbcUtil.prepareStatement(conn, sql, isCallable);
        JdbcUtil.setParameters(pst, params);
        rs = pst.executeQuery();
        int cols = rs.getMetaData().getColumnCount();
        
        while(rs.next())
        {
            Object[] objs = new Object[cols];
            for(int i = 0; i < cols; i++)
                objs[i] = rs.getObject(i + 1);
                
            result.add(objs);
        }
    }
    catch (SQLException e)
    {
        throw new JdbcException(e);
    }
    finally
    {
        JdbcUtil.closeSqlObject(pst, rs);
    }
    
    return result;
}

 

从中我们可以抽取的看到:

catch (SQLException e)
    {
        throw new JdbcException(e);
    }

jdbc执行SQL语句查询的时候,先抛出SQLException ,然后就像一条链一样,下一步告诉别人是JDBC的异常.下面体会经典,休息下:

 

大直若屈，大巧若拙，大辩若讷。躁胜寒，静胜热，清静为天下正。<道德经-老子>
最正直的东西，好似有弯曲一样；最灵巧的东西，好似最笨拙的；最卓越的辩才，好似不善言辞一样。清静克服扰动，赛冷克服暑热。清静无为才能统治天下

 

受检异常尽可能转化为非受检异常

所有受检异常(Checked Exception)是好事,为何要尽可能转化为非,也就是(Unchecked Exception)呢?我的理解是:受检异常威胁到系统的安全性,稳定性,可靠性,正确性时,不能转换为非受检异常.
也就是说,其中存在的受检异常有缺点,转换成Unchecked Exception就轻松解决了.

 

• 受检异常使接口声明脆弱

---

show the code:

interface User
{
    //修改用户名密码,抛出安全异常
    public void changePass() throws MySecurityException;
}

throws MySecurityException;

这里面不一定只是一个异常,然而定义了异常,会增加了接口的不稳定性,这就存在了面向对象设计的严重亵渎,如果要改变的话,又破坏了封装性.

另外,受检异常还有两个缺点:

• 受检异常使代码可读性降低
• 受检异常增加了开发工作量

 

 

多使用异常，把性能问题放一边

“性能问题不是拒绝异常的借口” 就当一个常见的登录用例.我们经常会添加一个例外的事件:”连续登录3次登录失败,暂时锁定用户帐号.”这样这个例外的事件就是一个异常处理.

 

show the code

public void login()
{
    try
    {
        // 正常登录
    } 
    catch (InvalidLoginNameException e)
    {
        // 用户名无效
    }
    catch (InvalidPasswordException e)
    {
        // 密码错误
    }
    catch (TooManyLoginsException e) 
    {
        // 多次登录失败
    }
}

这样子一来,代码逻辑很清晰.但是这样子就抛出了一个主意.这样子有代价:

性能比较慢

---

java的异常处理机制确实比较慢,这个性能慢是相对的.相对那些基础类型:String Integer…等.有人测试结果如下:

测试结果:
(运行环境:xen虚拟机,5.5G内存,8核;jdk1.6.0_18)
(10个线程,创建10000000个对象所需时间)
普通Java对象         45284 MS 
普通java异常        205482 MS 
改进的Java业务异常   16731 MS

相当于创建每个异常对象是普通对象的五倍.但是数量级上是 MS,在一个系统中,如此微小的性能消耗是可以允许的.

 

java web 中的异常处理

经验之谈:”用对了地方就好，用错了地方就不好。”这是我的师傅跟我说的,他教会了很多.太很抽象,我想我会慢慢学会的.

 

实际J2EE项目中,通常一个页面请求到达后台以后，首先是到MVC中的controller，在controller层会调用业务逻辑层service，而在service层会调用持久层dao进而获得数据，再将获得的数据一层一层返回到controller层，然后通过controller控制层转发到指定页面.

可能存在的异常:

• dao层可能会发生SQLException异常
• service层可能会发生NullPointException异常,
• controller层可能会发生IOException异常,RuntimeException异常

 

正确的处理方式

---

根据上面知识的说法:我们该用以下的方法来实现

• 提倡异常封装
• 采用异常链传递异常 [在这里我们举过,DAO层中jdbc操作怎么实现抛异常例子]

 

show the code:

@RequestMapping(value = "/courseTeacherRelationAdd")
public @ResponseBody String courseTeacherRelationAdd(String courseID,String teacherInfoID,CourseTeacherRelation courseTeacherRelation) 
{
    
    try
    {
        int sign = courseTeacherRelationService.saveOrUpdateCourseTeacherRelation(courseID,teacherInfoID,courseTeacherRelation);
        
        if( sign == Constant.RESULT_SUCCESS )
            return successResponse("保存成功","../courseTeacherRelation/courseTeacherRelations" , "courseTeacherRelations");
        
    }
    catch (Exception e)
    {
          throw new EntityException("Error！ when save the entity",e);
    }
    
    return failResponse("保存失败");
    
}

throw new EntityException("Error！ when save the entity",e);

这里用了链式异常抛出:EntityException是自定义的异常类:

public class EntityException extends RuntimeException 
{
    private static final long serialVersionUID = 1L;

    public EntityException() {
        super();
    }

    public EntityException(String message) {
        super(message);
    }

    public EntityException(String message, Throwable cause) {
        super(message, cause);
    }
}

 

自然还有些什么拦截器抛出异常,在这里就不详细展开讨论了.