J2EE项目异常处理 下(转)

3． 设计一个新的异常类
   在设计一个新的异常类时，首先看看是否真正的需要这个异常类。一般情况下尽量不要去设计新的异常类，而是尽量使用Java中已经存在的异常类。
    如IllegalArgumentException, UnsupportedOperationException

    不管是新的异常是chekced异常还是unChecked异常。我们都必须考虑异常的嵌套问题。

public void methodA()throws ExceptionA...{
…..
throw new ExceptionA();
}
    方法methodA声明会抛出ExceptionA.

    public void methodB()throws ExceptionB
    methodB声明会抛出ExceptionB,当在methodB方法中调用methodA时，ExceptionA是无法处理的,所以ExceptionA应该继续往上抛出。一个办法是把methodB声明会抛出ExceptionA.但这样已经改变了MethodB的方法签名。一旦改变，则所有调用methodB的方法都要进行改变。
    另一个办法是把ExceptionA封装成ExceptionB，然后再抛出。如果我们不把ExceptionA封装在ExceptionB中，就丢失了根异常信息，使得无法跟踪异常的原始出处。

public void methodB()throws ExceptionB...{
try...{
methodA();
……
}catch(ExceptionA ex)...{
throw new ExceptionB(ex);
}
}
    如上面的代码中，ExceptionB嵌套一个ExceptionA.我们暂且把ExceptionA称为“起因异常”,因为ExceptionA导致了ExceptionB的产生。这样才不使异常信息丢失。
    所以我们在定义一个新的异常类时，必须提供这样一个可以包含嵌套异常的构造函数。并有一个私有成员来保存这个“起因异常”。

public Class ExceptionB extends Exception...{
private Throwable cause;

public ExceptionB(String msg, Throwable ex)...{
super(msg);
this.cause = ex;
}

public ExceptionB(String msg)...{
super(msg);
}

public ExceptionB(Throwable ex)...{
this.cause = ex;
}
}
     当然，我们在调用printStackTrace方法时，需要把所有的“起因异常”的信息也同时打印出来。所以我们需要覆写 printStackTrace方法来显示全部的异常栈跟踪。包括嵌套异常的栈跟踪。

public void printStackTrace(PrintStrean ps)...{
if(cause == null)...{
super.printStackTrace(ps);
}else...{
ps.println(this);
cause.printStackTrace(ps);
}
}
    一个完整的支持嵌套的checked异常类源码如下。我们在这里暂且把它叫做NestedException

public NestedException extends Exception...{
private Throwable cause;
public NestedException (String msg)...{
super(msg);
}

public NestedException(String msg, Throwable ex)...{
super(msg);
This.cause = ex;
}

public Throwable getCause()...{
return (this.cause == null ? this :this.cause);
}

public getMessage()...{
String message = super.getMessage();
Throwable cause = getCause();
if(cause != null)...{
message = message + “;nested Exception is ” + cause;
}
return message;
}
public void printStackTrace(PrintStream ps)...{
if(getCause == null)...{
super.printStackTrace(ps);

}else...{
ps.println(this);
getCause().printStackTrace(ps);
}
}

public void printStackTrace(PrintWrite pw)...{
if(getCause() == null)...{
super.printStackTrace(pw);
}
else...{
pw.println(this);
getCause().printStackTrace(pw);
}
}
public void printStackTrace()...{
printStackTrace(System.error);
}
}
    同样要设计一个unChecked异常类也与上面一样。只是需要继承RuntimeException。

 

   4． 如何记录异常
    作为一个大型的应用系统都需要用日志文件来记录系统的运行，以便于跟踪和记录系统的运行情况。系统发生的异常理所当然的需要记录在日志系统中。

public String getPassword(String userId)throws NoSuchUserException...{
UserInfo user = userDao.queryUserById(userId);
If(user == null)...{
Logger.info(“找不到该用户信息,userId=”+userId);
throw new NoSuchUserException(“找不到该用户信息,userId=”+userId);
}
else...{
return user.getPassword();
}
}

public void sendUserPassword(String userId)throws Exception ...{
UserInfo user = null;
try...{
user = getPassword(userId);
//……..
sendMail();
//
}catch(NoSuchUserException ex)(
logger.error(“找不到该用户信息:”+userId+ex);
throw new Exception(ex);
}
    我们注意到，一个错误被记录了两次.在错误的起源位置我们仅是以info级别进行记录。而在sendUserPassword方法中，我们还把整个异常信息都记录了。

    笔者曾看到很多项目是这样记录异常的，不管三七二一，只有遇到异常就把整个异常全部记录下。如果一个异常被不断的封装抛出多次，那么就被记录了多次。那么异常倒底该在什么地方被记录？
异常应该在最初产生的位置记录！

    如果必须捕获一个无法正确处理的异常，仅仅是把它封装成另外一种异常往上抛出。不必再次把已经被记录过的异常再次记录。

    如果捕获到一个异常，但是这个异常是可以处理的。则无需要记录异常

public Date getDate(String str)...{
Date applyDate = null;
SimpleDateFormat format = new SimpleDateFormat(“MM/dd/yyyy”);
try...{
applyDate = format.parse(applyDateStr);
}
catch(ParseException ex)...{
//乎略，当格式错误时，返回null
}
return applyDate;
}

捕获到一个未记录过的异常或外部系统异常时，应该记录异常的详细信息
try...{
……
String sql=”select * from userinfo”;
Statement s = con.createStatement();
……
Catch(SQLException sqlEx)...{
Logger.error(“sql执行错误”+sql+sqlEx);
}
    究竟在哪里记录异常信息，及怎么记录异常信息，可能是见仁见智的问题了。甚至有些系统让异常类一记录异常。当产生一个新异常对象时，异常信息就被自动记录。

public class BusinessException extends Exception ...{
private void logTrace() ...{
StringBuffer buffer=new StringBuffer();
buffer.append("Business Error in Class: ");
buffer.append(getClassName());
buffer.append(",method: ");
buffer.append(getMethodName());
buffer.append(",messsage: ");
buffer.append(this.getMessage());
logger.error(buffer.toString());

}
public BusinessException(String s) ...{
super(s);
logTrace();
}
}
    这似乎看起来是十分美妙的，其实必然导致了异常被重复记录。同时违反了“类的职责分配原则”，是一种不好的设计。记录异常不属于异常类的行为，记录异常应该由专门的日志系统去做。并且异常的记录信息是不断变化的。我们在记录异常同应该给更丰富些的信息。以利于我们能够根据异常信息找到问题的根源，以解决问题。
     虽然我们对记录异常讨论了很多，过多的强调这些反而使开发人员更为疑惑，一种好的方式是为系统提供一个异常处理框架。由框架来决定是否记录异常和怎么记录异常。而不是由普通程序员去决定。但是了解些还是有益的。

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系统级的异常严重的影响了我们的业务接口。我们对系统进行分层的目的就是减少系统之间的依赖，每一层的技术改变不至于影响到其它层。，

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异常。
定义一个checked的业务异常，让业务层的接口的所有方法都声明抛出unChecked异常.

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);
}
}
}

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从页面所有传给后台的参数都是字符型的，如果要求输入数值或日期类型的参数时，必须把字符值转换为相应的数值或日期值。
如果表示层代码校验参数不合法时，应该返回到原始页面，让用户重新录入数据，并提示相关的错误信息。

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

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异常，并给提示用户重新录入。

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’格式的日期”);
}

}

 

在表示层一定要弄清楚调用方法的是否会抛出unChecked异常，什么情况下会抛出这些异常，并作出正确的处理。
在表示层调用系统的业务方法，一般情况下是无需要捕获异常的。如果调用的业务方法抛出的异常相当于第二个返回值时，在这种情况下是需要捕获业务方法的异常并进行正确的处理。