使用try/catch語句

的智者，我希望這個話題不要太哲學:)使用try/catch語句

通常我開發一個應用程序，其中有很多與外部世界連接的。您可以保存和讀取文件，連接到數據庫，通過TCP協議讀取數據包，將打印任務發送到打印機，解析用戶文本輸入等。理論上這些操作中的每一個都可能以許多可能的方式出錯。

我的問題是，我厭倦了寫數百條指令的try/catch塊。它使代碼長兩倍，閱讀起來更糟糕，而不是做一些「真正的」編碼，我一直在寫日誌的消息，這可能永遠不會發生。

但是有沒有其他的選擇？

你的方法是什麼？使所有這些try/catch塊？或者只是忽略這些可能的錯誤，並在用戶報告之後才處理ACTUAL錯誤？

我們應該永遠不允許應用程序崩潰，我們應該預測用戶的任何愚蠢行爲還是用戶問題不要做愚蠢的行爲？

將大塊代碼放入try/catch或放入單個指令會更好嗎？

我很感激任何建議或只是意見。

2013-10-22 RRM

你遇到什麼樣的例外？你能展示一些示例代碼嗎？ – WarrenFaith

這一切都取決於你的代碼在做什麼，等等等等。在這種類型的決定中有很多變量。 – Liam

另一方面，你應該接受幾個答案。如果你這樣做，人們將更有可能提供幫助。 – Liam

如果部分代碼可能會中斷，則不應該使用異常。

例外情況是出於特殊情況！

This MSDN article暗示了一些明智的提示，即Tester-Doer模式和Try-Parse模式。

2013-10-22 08:55:40

不確定如何避免網絡驅動代碼的例外情況。這聽起來不像是他在控制流程中使用它們。 – usr

例外當然有它們的位置 - 這就是它們存在的原因，但OP確實會說「解析用戶文本輸入等等」，儘管...... –

您應該在可能實際失敗的部分周圍寫入try。這些通常是網絡操作本身，而不是其他所有的代碼。如果您使用try-保護太多的代碼，您將冒險捕獲網絡錯誤爲而非的例外，但是您的代碼可能會將它們誤認爲是這樣。

如果你有try -protect許多行（也許是因爲你正在做的細粒度與BinaryReader讀取），你可以把try的內容到一個單獨的方法。這擺脫了縮進，並隱藏了很多複雜性。 Resharper可以很容易地提取方法。

無論如何，您需要一個頂級異常處理程序來記錄通常爲錯誤的意外錯誤。這些也是如此。

只有當你能合理地處理錯誤，或者你記錄那個特定的錯誤並重新拋出時。我發現在大多數情況下，我只需要很少的catch處理程序，因爲大多數錯誤不能通過中止處理來處理。

2013-10-22 08:55:54 usr

回答