.net c# catch - 是“死亡是真棒”首選?




8 Answers

我認為這取決於你正在運行的是什麼類型的應用程序,以及“死亡”的後果是什麼。 對於許多客戶端應用程序,死亡是真棒。 對於服務器來說,通常不會太多(並且吞下並記錄是合適的)。 沒有一個萬能的解決方案。

all exception

最近我參加了Jeffrey Richter關於.NET的培訓課程。 他提到了一個編碼“死亡是真棒”的策略。 也就是說,即使在程序或事件循環的根部,也不要寫“catch(Exception ex)”。 如果拋出一些不能處理的異常,就讓進程死掉。

我不確定這是對的。 就個人而言,我更喜歡有一個“ try {...} catch(Exception ex) {log and try to recover} ”以包裝在執行的頂層。 實際上,如果有任何異常從asXx中拋出,ASP.NET不會死。 如果它死了,例外,那麼一個銀彈的請求可以沉默整個服務。

你怎麼看?




這一切都取決於你如何對待例外。 如果只在發生異常情況時(而不是在數據庫查詢沒有返回結果或不合格時)拋出異常,那麼您確實不需要捕獲異常。 因為你的程序不能恢復,所以你可以從中恢復的東西不是一個例外,而是一個錯誤。




卡爾·塞甘Karl Seguin )介紹了有關異常處理

  1. 只處理你實際上可以做的事情
  2. 絕大多數例外你都無能為力

很好的介紹主題。




如果你無法充分地處理這個問題 - 而且除了拒絕某種形式的錯誤輸入(這包括你試圖從磁盤或網頁上讀取的東西),你可能不會 - 那麼你應該死亡。 除非你100%確定你可以安全地繼續,否則不要。

但是,我不會簡單地讓異常去。 抓住它,並收集盡可能多的信息,你可以。 如果你的程序操作某種文件,將其保存在一個新的名稱下 - 可能是腐敗的,你不想覆蓋原文。




沒有什麼比堆棧跟踪更快地破壞用戶信心。 至少,抓住例外,並儘可能多地記錄信息。 然後向用戶提供一個友好的信息和指示,以便如何解決問題或報告問題以支持。

這裡有一個關於繼續處於不確定狀態的問題。 如果這是一個Web應用程序,那麼這不是一個問題,除非你過度依賴會話和應用程序狀態。 如果這是一個Windows應用程序,那麼隨時退出(給用戶一個保存的機會後)。




你的客戶期望什麼?

這一切都回來了。 如果客戶可以處理程序死機,並且可以重新啟動,那就這樣做吧。

有時候,最好讓一個進程死掉,創建另一個來處理請求。

有時候,最好試圖解決這個問題。




有一個不處理任何例外的好處。 如果出現問題,您寧可發生崩潰,用戶也要抱怨,而不是讓程序繼續處於不確定狀態。

例如,如果你正在寫一個實時交易系統,並且有一個意外的錯誤,你最好讓它崩潰。 否則,你的計劃可能會繼續下去,並做出愚蠢的交易。 用戶會馬上抱怨“跆拳道?”,但至少你不會損失數百萬美元。




試圖抓住一切的問題是,你經常最終'處理'你不知道如何恢復的事情。 用戶會得到錯誤印象,認為事情進展順利,但在內部你轉向瑞士奶酪,最終以非常奇怪的方式破門而入。

另一方面,向用戶拋出異常並不是那麼有用,因為他們沒有辦法報告它

  • 當您向MS註冊時,新的Windows服務提供該功能。
  • 安裝drwatson也可以捕獲用戶手動發送給你的數據(轉儲文件)。

如果你提供了一個服務庫,並且它正在運行,如果你的服務混淆了整個服務器的內存或設置等等,那麼服務器可能會在引發異常時關閉。

通過契約,API將傾向於提供一種方式來說'我可以這樣做',然後'做到這一點',許多API(如打開的MS文件)將允許您在引發異常和返回錯誤代碼之間進行更改。




Related