为什么要在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中获取错误信息,显示在前台页面上。当然,我们也可以选择更人性化得处理方案,比如说,放个失望的表情,写上“抱歉,服务器内部错误,您可以发邮件给我们提示此错误,xxxx@xxxx.com”等等;