2012-11-18 61 views
6

我已閱讀並現在討論以下問題,深刻的文章和其他許多人在過去:我應該用try-catch語句附上哪些類型的代碼塊?

When to use try/catch blocks?

Main method code entirely inside try/catch: Is it bad practice?

When to use Try Catch blocks

我將這篇文章的編碼標準在我的組織中處理異常!艾利不錯的人,但沒有回答我: http://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

What is the Best practice for try catch blocks to create clean code?

Best practices for exception management in Java or C# 這裏:我不喜歡這個statment :( 你不應該試圖抓住每一個例外,在一切可能的地方。

Should multiple Try/Catch blocks in a method be combined

我有一個問題,當我需要決定附上與try-catch語句代碼塊一些,我知道應該封閉代碼是個e有缺陷的代碼,並且我必須檢查我可以檢查的內容,但是例如: 我需要在某些文本文件中寫入一行,我應該檢查該文件是否存在,並且如果我有權寫入它,是否應該檢查磁盤上是否有空間,或者磁盤是否可寫,如果我檢查了空間,如果在寫入文件時發生了什麼(某些其他應用程序或線程使用了空間,或者可移動驅動器已被刪除? ),如果我檢查了這些東西並處理了IOException和SecurityException以及其他潛在異常,那麼這是否是一種最佳做法?或者我應該只檢查而不嘗試捕獲?

另一個例子: 我使用EntityFramework來訪問數據庫,當訪問某些東西時可能會聯繫數據庫,我知道我應該檢查連接是否關閉並嘗試打開它,但有很多很多事情可能會導致失敗在此聲明中,數據庫可能位於可移動驅動器上,讀取時該驅動器可能會被刪除,DBMS的服務可能因任何原因停止,不會引發空間異常,但在嘗試訪問數據庫後,數據庫的方案可能會更改執行我的代碼有一些****的原因,我怎樣才能防止我的代碼失敗,我可以檢查我可以檢查的每一件事,然後繼續?或者我應該使用try catch來解決我可以期待的異常,即使我已經檢查過它們了嗎?

請給我參考你的答案請不要一般的答案!

編輯

而且肯定閱讀: http://msdn.microsoft.com/en-us/library/seyhszts.aspx

+0

如果您投了票,請發表評論! –

+0

你只關心爲什麼它失敗了,如果你可以或者願意,做的工作糾正它的代碼。否則,您可以只記錄異常並重新拋出。大多數應用程序不需要你提出的那種健壯性,有的可以。 – PatFromCanada

回答

4

問得好!其中一個鏈接(Daniel Turini)是我的最愛之一。當我的思想需要一些理順時,我會一再回顧它。

表達我的態度,異常處理的一個好方法是:只有手柄例外,你可以處理。這意味着你永遠無法解決出現的任何可能的異常,並在你的代碼中實現它。有一些可以處理的「預期」異常 - 但代碼對此做出的反應本身就是一個設計決策。恕我直言,在處理這些問題時的優先權並不是在應用程序關閉後(或至少退出它涉及的特定事務)留下一絲混亂 - 而不是,因爲應用程序無論如何都是可以進行的,因爲用一個優雅的「我不知道爲什麼,但這個異常發生」通知(對於日誌/ IT電子郵件/ MsgBox,無論如何)關閉是某種「壞事」。

這種設計的直接反面是那種試圖使應用程序成爲一種「核大決戰 - 倖存者」的異常處理。 嘗試 ...我見過通過假設網絡文件服務器關閉來響應IO錯誤的代碼,並且嘗試在C:驅動器上以某種不合意的方式嘗試工作。並嘗試SELECT FROM ATable的代碼:如果表不存在,它創建它!每當有人寫這樣的代碼,一個嬰兒負鼠死亡。

Turini說「永遠不會吞下例外」。我在想的是這個擴展:恕我直言,你必須非常小心地讓應用程序繼續進行,即使是對已知的明確類型的異常做出響應,並帶有已知的原因:因爲即使這構成了「吞食」異常。做到這一點,但要小心翼翼地做好。

因此,在我的思維方式中,通常存在一個通用的「任何其他情況」異常處理程序的空間,它通過記錄發生的事件的細節並將其關閉而將決策委託給更高的權力(人類)應用程序。

我2C ..

+0

我認爲正確的做法應該是確保意外的異常使任何可能由於意外偏離正常執行順序而被破壞的數據結構失效。如果代碼可以在沒有這些數據結構的情況下生存下如果不能,則使數據結構無效將確保其快速死亡。如果代碼調用'LoadDocument'並得到一個異常,它不應該知道所有可能的原因,該操作可能無法知道它是否應該崩潰或者只是報告文件不能被讀取。 – supercat

0

恕我直言:抓住每一個例外,在您的應用程序,以防止你的應用程序被撞壞,(在UI的最後一層,你的控制檯應用程序的身體,或身體一些服務方法等),並處理它,如果你可以或至少記錄它,但在內部層次中,只捕獲你只知道處理它們的異常,拋出或包裝那些沒有完美的異常但如果你的代碼在圖層之間沒有明確的界限(在我的情況下是相同的),你應該儘可能地處理異常,並嘗試重置(重寫)這個應用程序(就像我們很快會做的那樣!)一個結構良好的方式!

相關問題