Java Web應用程序中的異常處理

Question

我正在開發一箇中等大小的Java Web應用程序，其中使用Struts作爲MVC框架和數據訪問層的簡單JDBC。我一直在尋找這種應用程序中的異常處理最佳實踐。我發現了幾篇文章，其中有些文章是矛盾的，只會讓我更加困惑，而不是把事情弄清楚和簡單。有人說，重複使用現有的異常而不是定義特定於應用程序的異常會更好，其他人則會針對系統中可能出現的每一個小問題展示巨大的應用程序特定異常層次。有人說最好不要在數據訪問層處理異常並將它們委託給服務層，另一些人則認爲數據訪問層異常應該在本地捕獲，因爲將它們委託給服務層會違反兩層之間的抽象。等等。

如果你讓我知道文章/書籍的鏈接/名稱，以表明在這種情況下爲你工作的固體解決方案，我將非常感激。解決方案應該至少清除以下幾點，並說明理由：

1. 哪裏發現SQLE錯誤？
2. 如何記錄異常？
3. 是否應該記錄未檢查的異常？
4. 應該在表示層捕獲未經檢查的異常，並且它們是否應該顯示給用戶？
5. 如何檢查異常處理，哪些要顯示給用戶以及如何處理？
6. 應該如何使用全局異常處理程序頁面？
7. 在這種情況下應該如何使用struts ActionErrors？

感謝

Answer 1

1：哪裏發現SQLExceptions？

在數據訪問層的DAO類。如有必要，可以用自定義的DAO異常包裝它。這個DAO異常又需要作爲檢查異常進一步處理。

2：哪裏應該記錄異常？

當你到達throw或者通過消息框架。

3：是否應該記錄未經檢查的異常？

他們當然應該被記錄。它們應該是而不是發生在現實世界中，因爲這些都是代碼邏輯（即開發人員故障）中的故障的跡象，需要儘快修復。應將它們一直扔到容器中，讓容器用<error-page>在web.xml中處理它們。要記錄（並最終發送郵件），請使用在錯誤頁面上偵聽的Filter。

4：應該在表示層捕獲未檢查的異常，並且它們是否應該顯示給用戶？

它們不應該發生。

5：如何檢查異常處理，哪些要顯示給用戶以及如何處理？

如果它們是錯誤的用戶輸入（例如不是數字，錯誤的電子郵件，違反約束等）的結果，則以與用戶相同的形式顯示它們。否則（例如數據庫關閉，DAO異常等）要麼一直拋出錯誤頁面，要麼顯示錯誤消息並稍後重試。

6：應該如何使用全局異常處理程序頁面？

至少以用戶友好的方式。因此，在相同的佈局中，有一些介紹性的「對不起」，如有必要，還有一些錯誤細節和電子郵件地址，以便用戶可以聯繫這種情況。

7：如何在此上下文中使用struts ActionErrors？

以相同的形式向用戶展示它們。

Answer 2

如果你不能從異常中恢復，那麼你就應該讓它（通過使選擇它，或在未經檢查的異常包裝往往）要流出來的代碼。如果他們仍然被檢查，你必須在你的代碼的每個級別，並因此在每個抽象層上迎合他們。 SQLExceptions通常會屬於這個類別（因爲它們被選中，你必須包裝它們）。

對於這些例外情況，我通常登錄最高級別，但向用戶展示一個頁面，只是詳細說明某些東西出錯了。通常我的用戶對堆棧跟蹤不感興趣。但我通常爲他們提供一個頁面讓他們描述他們當時正在做什麼，並且記錄的異常通過唯一的id（記錄在表單和日誌文件中除外）與此提交相關聯。這使我可以將用戶的行爲與產生的異常聯繫起來。

上面假設你不能從SQLExceptions中恢復，並且如果數據庫關閉，那麼你不能做一些有意義的事情。當然，這也有例外。您可能會發現您正在與多個系統通話，而一個系統正在關閉並不意味着您無法以某種方式繼續（例如，據報道，亞馬遜主頁依賴於100個服務，無論其中有些服務是否需要運行下）。

我認爲聲明異常與定義它們的接口/方法處於相同的抽象層次。例如一個TradeStore將被宣佈爲拋出TradeException，而不是SQLException（因爲存儲交易的方法是TradeStore的實現 - 您可以存儲在關係數據庫，JavaSpace等中）。

Answer 3

作爲警告，向用戶顯示較低級別的錯誤消息時，請確保它們已經過系統信息清理。這是許多安全漏洞的起源地區。用完整信息記錄它們，但僅向用戶顯示更一般的錯誤消息。