异常管理

[b]JVM 异常[/b]：这种类型的异常由 JVM 抛出。 OutOfMemoryError 就是 JVM 异常的一个常见示例。对 JVM 异常您无能为力。它们表明一种致命的情况。唯一得体的退出办法是停止应用程序服务器（可能要增加硬件资源），然后重新启动系统。

[b]应用程序异常[/b]：应用程序异常是一种定制异常，由应用程序或第三方的库抛出。这些本质上是受查异常（checked exception）；它们预示了业务逻辑中的某个条件尚未满足。在这样的情况下，EJB 方法的调用者可以得体地处理这种局面并采用另一条备用途径。

[b]系统异常[/b]：在大多数情况下，系统异常由 JVM 作为 RuntimeException 的子类抛出。例如， NullPointerException 或 ArrayOutOfBoundsException 将因代码中的错误而被抛出。另一种类型的系统异常在系统碰到配置不当的资源（例如，拼写错误的 JNDI 查找（JNDI lookup））时发生。在这种情况下，系统就将抛出一个受查异常。捕获这些受查系统异常并将它们作为非受查异常（unchecked exception）抛出颇有意义。最重要的规则是，如果您对某个异常无能为力，那么它就是一个系统异常并且应当作为非受查异常抛出。

原则:
数据访问层发生的异常都是跟数据库相关的不可恢复的异常,简单封装成DataAccessException抛出。

业务层捕获数据访问层抛出的异常,将其封装成各种有业务含义的自定义异常,例如:UserSaveFailedException。
以Spring为例,在业务层用AspectJ捕获异常,把异常堆栈作为debug信息输出到控制台,业务异常对应的message信息输出到日志作记录。

表现层只关心业务相关异常,捕获到异常后进行错误处理,跳转到友好的异常界面。

详细的异常堆栈信息提供给开发查看,直接在控制台输出;
相对友好的业务异常信息提供给系统管理员查看,分析;
对于最终用户只提供友好的异常界面,不能让其觉得是系统出大问题了。

配置如下:(以Spring2.5为例)

@AfterThrowing(pointcut="execution(* shskey.portal.service..*.*(..))", throwing="ex")
	public void afterServiceThrowing(ApplicationException ex) {
    	StringWriter stringWriter = new StringWriter();
    	PrintWriter printWriter = new PrintWriter(stringWriter);  
    	ex.printStackTrace(printWriter);
    	logger.debug(stringWriter.toString());
    	// Logged it.
    	logger.error("After throw exception : "+ex.getMessage());
	}

页面直接重定向到error page:
(以struts2为例)

<global-results> 
<result name="error">error.jsp</result> 
</global-results> 

<global-exception-mappings> 
<exception-mapping result="error" exception="shskey.protal.common.exception.BusinessException"></exception-mapping> 
</global-exception-mappings>

如果想在异常页面上显示些业务异常的消息,可以通过struts2提供的拦截器处理

<interceptors> 
  <interceptor name="exception" class="com.opensymphony.xwork.interceptor.ExceptionMappingInterceptor"></interceptor> 
  <interceptor name="exceptionInceptor" class="shskey.protal.common.interceptor.ExceptionInterceptor"></interceptor> 
</interceptors>