为什么要在JEE项目中谈异常处理呢？
可能许多java初学者都想说：“异常处理不就是 try….catch…finally吗？这谁都会啊！”。其实想的太简单了，异常就是当前程序不能处理抛出错误时，此时你有两种处理方法：1、使用try….catch…finally你来捕获，2、继续抛出异常，由下一个使用当前程序的程序员来处理。这样让程序继续正常执行...
而在JEE项目中，你要考虑，如何在一个多层的jee项目中定义相应的异常类？在项目中的每一层如何进行异常处理？异常何时被抛出？异常何时被记录？异常该怎么记录？何时需要把 checked Exception转化成unchecked Exception ，何时需要把unChecked Exception转化成checked Exception?异常是否应该呈现到前端页面？如何设计一个异常框架？
比如：
-
public Article getArticle(int id) throws HibernateException { //处理文章的Dao类 ArticleDao articleDao= new ArticleDaoImpl(); //定义返回文章的类 Article result = null; Session session = null; Transaction tx = null; //获得session session = HibernateUtil.getSession(); tx = session.beginTransaction(); // result = articleDao.get(id, session);/////////假如在这个地方发生了异常 ，没有捕获而是抛出 tx.commit(); //关闭session HibernateUtil.closeSession(session); return result; }
那么，session就没有关闭....此时抛出异常是不正确的。你应当关闭之后抛出。下面我就来讲讲struts2的异常声明式处理。。。如果要更加理解异常的话，我给出一个连接：
在struts2应用程序中你还在使用try catch语句来捕获异常么？如果是这样的，那你OUT啦！struts2支持声明式异常处理，可以再Action中直接抛出异常而交给struts2来 处理，当然需要我们在xml文件中配置，由于抛出同样的异常的处理方法通常都一样，所以如果能在xml中配置全局异常，将会使得开发便捷性大大提高。
以前的异常捕获可能是这样的：
/**
* 执行更新
*
* @return
*/
public String update() {
Article article = new Article();
article.setContent(content);
article.setTitle(title);
article.setId(id);
try {
articleService.update(article);
return SUCCESS;
} catch (SQLException e) {
e.printStackTrace();
return ERROR;
} catch (InvalidInputException e) {
e.printStackTrace();
System.out.println( "输入非法" );
return ERROR;
}
}
这种方式是完全的手动处理异常，一来不够简洁明快，而且还不容易维护，毕竟如果修改了这些代码都需要再次编译。
采用struts2的声明式异常处理就会简单很多了。
首先，上面的代码的try catch 就可以全都不要了，但是，当然，得新加throw语句抛出异常：
/**
* 执行更新
*
* @return
* @throws InvalidInputException
* @throws SQLException
*/
public String update() throws SQLException, InvalidInputException {
Article article = new Article();
article.setContent(content);
article.setTitle(title);
article.setId(id);
articleService.update(article);
return SUCCESS;
}
代码清晰了很多，不是么？
捕获异常的任务则交给xml配置文件了，配置文件还是比较容易理解的：
< package name = "wow" extends = "struts-default" >
< global-results >
< result name = "sql" >/internal_Error.jsp</ result >
< result name = "invalidinput" >/invalid_Input.jsp</ result >
< result name = "naming" >/internal_Error.jsp</ result >
</ global-results >
< global-exception-mappings >
< exception-mapping result = "sql" exception = "java.sql.SQLException" ></ exception-mapping >
< exception-mapping result = "invalidinput"
exception = "cn.codeplus.exception.InvalidInputException" ></ exception-mapping >
< exception-mapping result = "naming"
exception = "javax.naming.NamingException" ></ exception-mapping >
</ global-exception-mappings >
< action name = "*_*" class = "cn.codeplus.action.{2}Action" method = "{1}" >
< result name = "success" >/{1}_{2}_success.jsp</ result >
< result name = "error" >/{1}_{2}_error.jsp</ result >
<!--<exception-mapping result="sql" exception="java.sql.SQLException"></exception-mapping>-->
</ action >
</ package >
|
用于异常处理的<exception-mapping>标签可以配置在Action中，也可以配置在<global-exception-mappings>，顾名思义 <global- exception-mappings>就是全局异常，当然执行Action的时候发生异常时，如果在Action中没有捕获异常而是抛出异常的 话，struts2会首先在正在执行的Action中查找<exception-mapping>，寻找对应的Exception进行处理， 如果找不到，才会去<global-exception-mappings>去寻找对应的Exception处理，如果还是找不到的话，就只 好抛出异常了。
下面说说异常处理：
< exception-mapping result = "sql" exception = "java.sql.SQLException" ></ exception-mapping > |
上面代码说明，当捕获java.sql.SQLException时候，去寻找对应的result为sql的视图返回，即<global- result>中name为sql的result去返回internal_Error.jsp。当然如果<exception- mapping>配置在action中的话，则会首先去action的result搜寻返回视图，失败了才会去搜寻<global- result>。
在我们编写上面的xml配置的时候可能会遇到如下错误：
这个是因为，我们xml配置文件各个标签<action>、<global-result>、<global-exception-mapping>的顺序不对，调整一下标签的顺序，符合黄色的提示语即可。
最后，我们说说视图层怎样获取异常信息，invalid_Input.jsp 文件是这样的：
<%@taglib prefix="s" uri="/struts-tags"%>
...
< body >
< jsp:include page = "nav.jsp" ></ jsp:include >
< div >
抱歉，服务器内部错误。
</ div >
< div >
< s:property value = "exception.message" />
</ div >
< s:debug ></ s:debug >
</ body
<
s:property
value
=
"exception.message"
/>表示从valuestack中获取错误信息，显示在前台页面上。当然，我们也可以选择更人性化得处理方案，比如说，放个失望的表情，写上“抱歉，服务器内部错误，您可以发邮件给我们提示此错误，[email protected]”等等；