N层结构的J2EE项目中的异常处理之四转载

最新推荐文章于 2024-11-04 20:33:37 发布

asdfnike

最新推荐文章于 2024-11-04 20:33:37 发布

阅读量872

点赞数

分类专栏： JAVA 文章标签： string exception interface 分布式应用 java class

JAVA 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

5．J2EE项目中的异常处理

目前,J2ee项目一般都会从逻辑上分为多层。比较经典的分为三层：表示层，业务层，集成层(包括数据库访问和外部系统的访问)。

J2ee项目有着其复杂性，J2ee项目的异常处理需要特别注意几个问题。

在分布式应用时，我们会遇到许多checked异常。所有RMI调用（包括EJB远程接口调用）都会抛出 java.rmi.RemoteException;同时RemoteException是checked异常，当我们在业务系统中进行远程调用时，我们都需要编写大量的代码来处理这些checked异常。而一旦发生RemoteException这些checked异常对系统是非常严重的，几乎没有任何进行重试的可能。也就是说，当出现RemoteException这些可怕的checked异常，我们没有任何重试的必要性，却必须要编写大量的 try…catch代码去处理它。一般我们都是在最底层进行RMI调用，只要有一个RMI调用，所有上层的接口都会要求抛出 RemoteException异常。因为我们处理RemoteException的方式就是把它继续往上抛。这样一来就破坏了我们业务接口。 RemoteException这些J2EE系统级的异常严重的影响了我们的业务接口。我们对系统进行分层的目的就是减少系统之间的依赖，每一层的技术改变不至于影响到其它层。

java 代码
//
public class UserSoaImpl implements UserSoa{
   public UserInfo getUserInfo(String userId)throws RemoteException{
      //……
远程方法调用.
      //……
   }
}
public interface UserManager{
   public UserInfo getUserInfo(Stirng userId)throws RemoteException;
}
同样JDBC访问都会抛出SQLException的checked异常。

为了避免系统级的checked异常对业务系统的深度侵入，我们可以为业务方法定义一个业务系统自己的异常。针对像 SQLException,RemoteException这些非常严重的异常，我们可以新定义一个unChecked的异常，然后把 SQLException，RemoteException封装成unChecked异常后抛出。

如果这个系统级的异常是要交由上一级调用者处理的，可以新定义一个checked的业务异常，然后把系统级的异常封存装成业务级的异常后再抛出。

一般地，我们需要定义一个unChecked异常，让集成层接口的所有方法都声明抛出这unChecked异常。

java 代码
public DataAccessException extends RuntimeException{
……
}
public interface UserDao{
public String getPassword(String userId)throws DataAccessException;
}

public class UserDaoImpl implements UserDAO{
public String getPassword(String userId)throws DataAccessException{
String sql = “select password from userInfo where userId= ‘”+userId+”’”;
try{
    …
     //JDBC调用
     s.executeQuery(sql);
    …
   }catch(SQLException ex){
      throw new DataAccessException(“数据库查询失败”+sql,ex);
   }
}
}
定义一个checked的业务异常，让业务层的接口的所有方法都声明抛出Checked异常.

java 代码
public class BusinessException extends Exception{
…..
}

public interface UserManager{
   public Userinfo copyUserInfo(Userinfo user)throws BusinessException{
      Userinfo newUser = null;
      try{
        newUser = (Userinfo)user.clone();
}catch(CloneNotSupportedException ex){
throw new BusinessException(“不支持clone方法:”+Userinfo.class.getName(),ex);
}
}
}
J2ee表示层应该是一个很薄的层，主要的功能为：获得页面请求，把页面的参数组装成POJO对象，调用相应的业务方法，然后进行页面转发，把相应的业务数据呈现给页面。表示层需要注意一个问题，表示层需要对数据的合法性进行校验，比如某些录入域不能为空，字符长度校验等。

J2ee从页面所有传给后台的参数都是字符型的，如果要求输入数值或日期类型的参数时，必须把字符值转换为相应的数值或日期值。

如果表示层代码校验参数不合法时，应该返回到原始页面，让用户重新录入数据，并提示相关的错误信息。

通常把一个从页面传来的参数转换为数值，我们可以看到这样的代码

java 代码
ModeAndView handleRequest(HttpServletRequest request,HttpServletResponse response)throws Exception{
   String ageStr = request.getParameter(“age”);
   int age = Integer.parse(ageStr);
   …………

String birthDayStr = request.getParameter(“birthDay”);
SimpleDateFormat format = new SimpleDateFormat(“MM/dd/yyyy”);
Date birthDay = format.parse(birthDayStr);

}
上面的代码应该经常见到，但是当用户从页面录入一个不能转换为整型的字符或一个错误的日期值时，

Integer.parse()方法被抛出一个NumberFormatException的unChecked异常。但是这个异常绝对不是一个致命的异常,一般当用户在页面的录入域录入的值不合法时，我们应该提示用户进行重新录入。但是一旦抛出unchecked异常，就没有重试的机会了。像这样的代码造成大量的异常信息显示到页面。使我们的系统看起来非常的脆弱。

同样，SimpleDateFormat.parse()方法也会抛出ParseException的unChecked异常。

这种情况我们都应该捕获这些unChecked异常，并给提示用户重新录入。

java 代码
ModeAndView handleRequest(HttpServletRequest request,HttpServletResponse response)throws Exception{
   String ageStr = request.getParameter(“age”);
String birthDayStr = request.getParameter(“birthDay”);
   int age = 0;
Date birthDay = null;
try{
age=Integer.parse(ageStr);
   }catch(NumberFormatException ex){
     error.reject(“age”,”不是合法的整数值”);
   }
   …………

try{
SimpleDateFormat format = new SimpleDateFormat(“MM/dd/yyyy”);
birthDay = format.parse(birthDayStr);
}catch(ParseException ex){
error.reject(“birthDay”,”不是合法的日期，请录入’MM/dd/yyy’格式的日期”);
}

}