簡介: 在C# Windows Forms應用程式中的錯誤處理

在"C# App From Start to Finish"系列的第25課，Tim Corey集中討論了一個重要但經常被誤解的主題：在C# Windows Forms應用程式中的錯誤處理。 Tim說明錯誤處理不僅僅是到處丟出try-catch區塊，而是關於有意識地設計您的應用程式如何回應無效的輸入、意外情況和使用者錯誤。

在這堂課中，Tim通過真實的範例展示了早先系列中建立的Tournament Viewer表單。 通過觀看錯誤如何發生以及它們應該如何處理，我們獲得了更深刻、更實際的理解，了解何時該讓應用程式失敗，何時該停止執行，以及何時該用有意義的反饋來引導使用者。 讓我們按步就班地直接從影片中詳細觀看Tim的講解。

理解問題：未處理的例外

課程開始時，Tim介紹了目標：為現有的Tournament Viewer表單增加基本的錯誤處理。 他立即展示了一個真實的問題——當兩支隊伍被賦予相同的分數並點擊"Score"按鈕時，應用程式拋出了一個例外。

Tim解釋說，雖然這種行為在Visual Studio中是可見的，但對於最終使用者來說，情況更糟。 如果應用程式是作為.exe運行的，錯誤訊息會出現，然後一旦消息框關閉，應用程式將崩潰。 Tim強調說，這對於面向使用者的應用程式來說是不能接受的行為。

為什麼統一的Try-Catch區塊是一個壞主意

然後Tim討論了一個常見的錯誤，開發人員犯的錯誤：將整個方法包裹在try-catch區塊中並稱之為"錯誤處理"。他強烈批評這種方法，稱其更接近於"吃掉錯誤"而不是實際處理。

在這一點上，Tim解釋了一個重要的理念：如果應用程式以意想不到的方式失敗，它應該非常明顯地失敗。 默默隱藏錯誤使除錯變得困難，並允許損壞的狀態傳播。 錯誤應該被截取的唯一時間是當它們是預期的並由使用者引起的。

在UI層中的有針對性的Try-Catch

Tim展示瞭如何僅將try-catch區塊應用於可能失敗的程式碼行周。 他演示了將得分邏輯用try區塊包圍，並用命名變數捕捉Exception。

Tim在此處強調了兩個最佳實踐：

• 始終命名您的例外變數，以便您可以存取其詳細資訊。

• 永遠不要使用throw ex; 因為它會破壞重要的堆棧跟蹤資訊。 相反，使用throw; 當需要重拋時。

在這種情況下，由於錯誤發生在UI中，Tim選擇在那裡直接通過顯示一個包含例外消息的MessageBox來處理它。

使用MessageBox改進使用者反饋

Tim增加了一個MessageBox.Show調用，它顯示一個明確的錯誤消息給使用者。 當再次輸入相同分數時，應用程式現在顯示：

"應用程式發生以下錯誤：我們不允許此應用程式中的平手。"

Tim指出，這已經是一個很大的改善。 錯誤得到處理，資料庫未更新，應用程式繼續安全運行。

永遠不要相信使用者：輸入驗證

Tim的一個核心原則在這裡明確重複： 永遠不要相信使用者。

在這個階段，應用程式假設使用者將輸入有效的數字分數。 Tim解釋為什麼這樣做是危險的，並引入在嘗試處理前驗證使用者輸入的想法。

他建立了一個名為IsValidData的私人方法，它檢查：

• 是否兩個分數輸入都是有效的數字

• 是否兩個分數均為零

• 分數是否平手

最初，此方法返回一個bool，允許調用程式碼停止執行並顯示通用錯誤消息。

從布林驗證到描述性錯誤

Tim對通用的"您需要輸入有效資料"消息不滿意。 他解釋說，良好的錯誤處理應該告訴使用者究竟發生了什麼錯誤。

為了改善這一點，他將驗證方法更改為返回字串而不是布林。 空字串意味著沒有錯誤； 否則，字串包含特定消息，例如：

*"分數1的值不是有效數字"

*"您沒有為任何一隊輸入分數"

*"我們不允許此應用程式中的平手"

這使UI能顯示有針對性、有意義的消息，而不是模糊的警告。

使用Else-If Chains修復邏輯錯誤

測試後，Tim注意到一個邏輯缺陷：無效的數字輸入有時會觸發"平手不允許"消息。 他解釋了為什麼會發生這種情況——失敗的數字解析將值設為零，分開的if語句允許後面的條件覆蓋先前的消息。

為了解決這個問題，Tim將驗證檢查轉換為一個else-if連鎖。 這確保了一旦滿足一個錯誤條件，其餘條件就會被跳過。 Tim解釋說，這使邏輯更清晰、更安全、且更容易維護。

錯誤處理不僅僅是Try-Catch

Tim回過頭來澄清了一個關鍵要點： 錯誤處理並不總是意味著使用try-catch區塊。

手動驗證——在處理前檢查使用者輸入——同樣重要。 通過提前驗證，應用程式防止了不良資料進入資料庫或業務邏輯。

他還解釋說，不是所有事情都需要驗證。 像下拉列表和清單方塊這樣的封閉系統已經限制了輸入。 然而，自由文字欄位必須始終進行驗證。

錯誤處理應該在哪裡運行

在課程結束時，Tim回答了一個常見問題：錯誤處理應該放在哪？

他的經驗法則：

• 驗證應該存在於整個應用程式中，包括後端。

• 例外通常應該在前端捕捉，因為這是使用者可以被通知的地方。

Tim指出，後端例外處理只有在系統可以恢復時才有意義，例如當SQL資料庫不可用時切換到文字文件。

對錯誤處理的最終思考

Tim總結強調說，良好的錯誤處理提高了應用程式的穩定性、使用者體驗和長期維護性。 他警告不要使用統一的try-catch區塊，並鼓勵開發人員有意識地思考驗證和例外流程。

這節課奠定了構建可靠的Windows Forms應用程式的基礎——那些可以引導使用者，保護資料，以及在必要時安全失敗的應用程式。