介紹：在 C# Windows Forms 應用程式中處理錯誤

了解問題：未處理例外

在課程開始時，Tim介紹了目標：為現有的比賽查看器表單添加基本的錯誤處理。 他立即展示了一個真實問題——當兩隊得到相同分數並點擊"Score"按鈕時，應用程式會拋出異常。

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

為何粗略的Try-Catch區塊是不好的主意

然後Tim討論了一個開發者常犯的錯誤：將整個方法包裹在try-catch區塊中，並稱之為"錯誤處理"。他強烈批評這種做法，認為這更接近於"錯誤吞沒"而非真正的處理。

大約在這個時候，Tim 解釋了一個重要的哲學：如果一個應用程式以意想不到的方式失敗，那麼它應該以顯著的方式失敗。 靜默隱藏錯誤會使除錯變得更困難，並允許腐敗的狀態擴散。 只有當錯誤是預期且由使用者造成時，才應該攔截錯誤。

UI層的針對性Try-Catch

而不是把所有東西都包裹起來，Tim 示範了如何僅在可能失敗的程式碼行周圍應用 try-catch 區塊。 他演示將計分邏輯包圍在try區塊中，並使用命名變量捕捉Exception。

Tim強調了這裡的兩個最佳做法：

始終為您的異常變量命名，以便您可以訪問其詳細資訊。

絕不要使用 throw ex; 重新拋出。 因為它會破壞重要的堆疊追蹤資訊。 改為使用 throw; 如果需要重新拋出。

在此情況下，由於錯誤發生在UI中，Tim選擇直接在那裡處理，通過顯示一個帶有異常信息的MessageBox。

使用訊息框改善使用者反饋

Tim 添加了一個 MessageBox.Show 調用，以顯示明確的錯誤訊息給用戶。 當再次輸入平分時，應用程式現在顯示：

"應用程式發生以下錯誤：我們不允許此應用程式中的並列情況。"

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

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

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

在這個階段，應用程式假設使用者會輸入有效的數字分數。 Tim解釋了為什麼這樣做是危險的，並介紹了在嘗試處理之前驗證用戶輸入的概念。

他創建了一個名為IsValidData的私有方法來檢查：

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

無論兩個分數是否皆為零

無論分數是否持平

最初，此方法返回一個 bool，允許呼叫代碼停止執行並顯示通用錯誤訊息。

從布林驗證到描述性錯誤

Tim對通用的"您需要輸入有效數據"訊息不滿意。 他解釋說，良好的錯誤處理應該明確告訴使用者到底出了什麼問題。

為了改進這一點，他將驗證方法的返回類型從boolean更改為string。 空字串表示沒有錯誤。 或者，該字串包含特定的訊息，例如：

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

"您未輸入任何一隊的得分"

"我們不允許在此應用程式中有平局"

這使得UI可以顯示針對性的、有意義的訊息，而不是模糊的警告。

使用Else-If鏈修正邏輯錯誤

在測試之後，Tim 注意到一個邏輯漏洞：無效的數字輸入有時會觸發"不允許平局"的信息。 他解釋為什麼會發生這種情況——失敗的數字解析會將值設為零，而單獨的if語句允許後面的條件覆蓋較早的訊息。

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

錯誤處理不僅僅是Try-Catch

Tim退後一步，澄清一個關鍵的要點： 錯誤處理不一定總是意味著使用try-catch區塊。

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

他還解釋說並非所有事物都需要驗證。 封閉系統，如下拉選單和列表框，已經限制了輸入。 但是，自由文本欄位必須始終進行驗證。

錯誤處理應該在哪裡進行

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

他的經驗法則：

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

異常通常應該在前端捕獲，因為那是在可以通知使用者的地方。

Tim提到，後端異常處理只有在系統能夠恢復時才有意義——例如當SQL無法使用時，可以切換到使用文字檔作為資料庫。

關於錯誤處理的最後想法

Tim 結論強調，良好的錯誤處理能提升應用程式的穩定性、使用者體驗以及長期維護性。 他警告不要使用通用的try-catch區塊，並鼓勵開發者有意識地思考驗證和異常流程。

這節課程為構建穩健的Windows Forms應用程式打下基礎，這些應用程式能夠引導使用者、保護數據，並且在必要時安全地失效。