捕获意外异常是一种好习惯吗?

时间:2013-01-11 05:25:45

标签: java spring exception-handling

我正在使用Spring 3框架编写Web应用程序。考虑一下我有N个控制器的情况。每个控制器将请求委托给公开的服务并获取响应并返回给用户。

我想知道是否有更好的方法来捕获从控制器代码中抛出的意外运行时异常。我不想为每个控制器方法编写类似下面的内容。或者这是唯一的方式?

try {
     //call the service
} catch(ServiceException serviceEx) {
    //do process for know exception  
} catch(Exception ex) {
    //return generic error message.
}

我知道我们可以使用Spring Exception解析器。但是,当发生意外错误时,我不想显示不同的错误页面。我想在UI上显示一些通用错误消息作为我的小部件的一部分?

编辑:

我也不希望我的用户在尝试执行某些操作时看到异常堆栈跟踪。

孙大信

4 个答案:

答案 0 :(得分:3)

我认为抓住RuntimeException是不好的做法。最初RuntimeException被认为是编程错误的指示符(例如NullPointerException表示缺少null项检查)。而已检查的例外情况意味着指示程序可以从中恢复的错误(例如FileNotFoundException)。

今天的问题是许多框架使用RuntimeException s,其中应使用已检查的异常。因此,很难区分程序可以处理异常的情况和遇到编程错误(错误)的情况。

这是我个人对企业发展的看法。我知道大多数人都要求删除已检查的异常并将所有内容作为未经检查的异常处理(如在Scala中)。

答案 1 :(得分:2)

在我看来,你应该只捕获你可以恢复的代码中的异常。所有其他异常(已选中或未选中)应由一个超级异常处理程序捕获,该异常处理程序将记录异常并向用户显示一些通用错误页面(可能带有可用于查找异常内容的ID)。

例如,在struts2中你会这样:

<global-exception-mappings>
    <exception-mapping exception="java.lang.Exception" result="unrecoverableException"/>
</global-exception-mappings>

我从不使用spring mvc但是这篇文章似乎为你提供了一个超级异常处理程序的选项:

http://doanduyhai.wordpress.com/2012/05/06/spring-mvc-part-v-exception-handling/

答案 2 :(得分:1)

您可以使用此方法捕获运行时意外异常。

  try {
  ...
  } catch ( Exception e ) {
  throw new RuntimeException("msg",e);
  }  

答案 3 :(得分:0)

我认为RuntimeException是针对违约或某些不可恢复的错误等情况而设计的。大多数情况下,您应该让容器或一些外部基础设施为您处理它。或者你必须编写大量冗余代码来处理它们,这有点违背了Spring的设计理念。

在你的情况下,如果你真的需要将它们转移到其他一些通用消息,你可以利用一些过滤器或拦截器来捕获那些意外的RuntimeException。