放在哪裏嘗試捕捉

Question

考慮這種情況： 我有3層應用程序，當此按鈕，用戶點擊該按鈕事件處理函數調用BIZ層的方法是做什麼用的數據我的按鈕事件處理程序的供應，然後通過將數據發送到將數據發送到後端數據庫的數據訪問層。 問題是在哪裏放置try catch？在數據層中，在biz層中，在表示層中或者可以放在所有層中？在這種情況下代表異常處理的最佳策略是什麼？

Answer 1

一定會把一個嘗試捕捉最接近用戶 - 因爲在那個位置，你可以把它轉化爲對用戶有意義的事。如果你打算做一些與他們只能需要

更深層次的嘗試捕獲 - 例如，處理異常，或者是記錄並重新拋出異常。

Answer 2

我們遵循

不要捕捉異常，如果你不知道該怎麼辦。

我們從來沒有處理，我們不能處理或默認任何異常。它會冒泡，我們會在應用程序級別處理它。

說一下，如果您可以爲業務對象默認值，那麼您可以在業務層中處理它。

Answer 3

這隻取決於你真正想要做些什麼。通常我在業務層捕獲它，然後記錄它並可能調用一些ui函數向用戶顯示一條消息。

我考慮如何處理業務規則的錯誤。它應該與數據層或UI層分開。

Answer 4

一般的答案是：捕捉任何時候，你可以處理什麼被拋出。也就是說，這個決定很簡單。例如，捕獲創建您需要的對象時出現的異常。

Answer 5

也許最好使用嘗試捕捉所有層，但只能默默趕在UI層的異常。在biz和數據訪問層中，你應該捕獲異常並記錄信息，然後再重新拋出。

try 
{ 
    //do something 
} 
catch(Exception ex) 
{ 
    LogFile.WriteLine(ex.ToString()); 
    throw; 
} 

注意：不要寫：

throw ex; 

，因爲這將清除所有從異常有用的堆棧信息。

Answer 6

總是嘗試/趕上最高級別或控制器級別。

Answer 7

UI僅供演示。你不會在那裏發現異常，因爲弄清楚如何處理它意味着邏輯。這屬於業務或控制器層。在最壞的情況下，您會捕獲異常並將其映射到適當的，用戶友好的錯誤消息，然後將其發送到演示文稿中進行顯示。

Answer 8

把try-catch放在你確定不會吞下異常的地方。如果可以確保一致性，則可以在各個圖層中使用多個try-catch塊。

例如，您可以在數據訪問層中放置try-catch，以確保正確清理連接。但是，由於你不能做更多的事情，你應該重新拋出異常。

移至業務層，您可以將try-catch跨多個數據庫操作（您希望以原子方式進行）。在這種情況下，可能應該回滾一切或將事物置於一致狀態，並在某處記錄異常。吞嚥或重新投射應根據具體情況決定。

您的表示層應始終捕獲所有異常，無論是某個Web應用程序，運行在瀏覽器中的腳本還是某些富客戶機應用程序。您可能無法完全理解異常，但至少可以確保您的應用程序不會在用戶面前死亡。

當然，它只是一個建議。因人而異。 :)

Answer 9

當我有一個這樣的多層架構（這是一個很多）時，我會經常有一個嘗試/抓住不止一層。例如，持久層中捕獲SQLException的try/catch，執行持久層需要做的事情（例如，通知管理員），然後拋出一個新的異常，這對調用持久層的代碼有意義。一個例子可能是PersistenceException。下一層不關心應該通知誰重新啓動數據庫，但它確實在意它不能保存用戶狀態，所以它可能會捕獲PersistenceException並告訴用戶他的新電話號碼不是'存儲在數據庫中。

Answer 10

異常處理的口頭禪是：「早投，遲到」。你想在最後時刻捕捉異常，但是你想立即拋出它們（在確定某些東西是錯誤的，然後拋出一個異常之後，不要執行更多的處理）。如果你不能「處理」這個異常，那麼不要抓住它。

在大多數情況下，Try ... Finally塊應該比Try ... Catch更常見。

Answer 11

您只想使用try catch來管理未處理的代碼。一個例子是我有一個COM對象與我交流，我不希望它保持開放，並創建一個內存泄漏。另一個可接受的選擇是在允許異常繼續之前捕獲數據庫中事件的錯誤。

你永遠不想使用try catch來處理你不確定代碼是否工作並想要備份計劃的情況。

那麼，當應用程序爆炸時，哪裏會留下你，使用自定義錯誤頁面來指示您的Web應用程序出現了問題，並且對於胖客戶端將代碼解析到工作線程中，以便它們不會炸燬主線程他們失敗了。祝你好運！