捕獲意外異常是一種好習慣嗎？

Question

我正在使用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上顯示一些通用錯誤消息作為小部件的一部分嗎？

編輯：

我也不想讓我的用戶在嘗試執行某些操作時看到異常stacktrace。

孫大信

Answer 1

我認為捕獲RuntimeException是一個壞習慣。 最初是RuntimeException ，在其中被認為是編程錯誤的提示（例如， NullPointerException表示缺少null檢查）。 而檢查異常則表示程序可以從中恢復錯誤（例如FileNotFoundException ）。

今天的問題是，許多框架都使用RuntimeException ，其中應使用檢查的異常。 因此，很難區分程序可以處理異常的情況和遇到編程錯誤（錯誤）的情況。

這是我對企業發展這件事的個人看法。 我知道大多數人都要求刪除受檢查的異常，並將所有內容作為未檢查的異常進行處理（例如在Scala中）。

Answer 2

我認為您應該只在代碼中捕獲可以從中恢復的異常。 所有其他異常（選中或未選中）都應由一個über異常處理程序捕獲，該異常處理程序將記錄該異常並向用戶顯示一些常規錯誤頁面（可能具有可用於查找異常的ID）。

例如，在struts2中，您希望這樣：

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

我從不使用spring mvc，但本文似乎為您提供über異常處理程序的選項：

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

Answer 3

您可以使用這種方法捕獲運行時意外異常。

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

Answer 4

我認為RuntimeException是為諸如違約或某些無法恢復的錯誤之類的情況而設計的。 大多數時候，您應該只讓容器或某些外部基礎結構為您處理它。 或者，您必須編寫很多冗余代碼來處理它們，這有點違背Spring的設計理念。

就您而言，如果確實需要將它們轉移到其他通用消息中，則可以利用某些過濾器或攔截器來捕獲那些意外的RuntimeException。