大學時的 C++ 課 (程設二) 第一次接觸例外處理，當時我自己在外面先學了 Java，所以優越的跟同學炫耀，但後來想想還真的沒什麼好炫耀的，只能說當時的自己有夠屁孩，也讓同學有不好的印象。

如今重新接觸，比起語法我覺得更重要的是拿來解決什麼問題。大部份是要讓程式執行過程中不要突然崩潰，所以引入例外處理，把這些錯誤或是例外能利用新加入的邏輯去解決它，但這個邏輯就需要與需求綁定。例如讀取的檔案不存在所以出錯了，那需求是希望或允許怎麼解決這個錯誤，比方說我們就回傳一個空字串，必須要有對應需求才能夠好好的解決。

中心思想

「預期世界可能會出錯，做好優雅的備案，而不是讓程式直接爆炸。」

什麼是「例外處理」？

「例外處理」 (Exception Handling)是程式在遇到錯誤或異常狀況時，能夠有條理地應對、不中斷地維持執行的方法。它的精神是: 把正常流程和錯誤處理分開來寫，讓程式既可保持結構清晰，又能面對不可預期的錯誤。

為什麼需要例外處理？

保持程式穩定性: 即使遇到錯誤，也能有優雅的應對方式，不至於整個程式當掉或卡住。
避免錯誤擴散**: 及早捕捉錯誤，阻止錯誤往後續流程傳播，減少災難。
提升可讀性和維護性: 把「正常邏輯」和「異常處理」分開，讓程式碼更乾淨、清楚。
有利除錯 (Debug): 可以清楚知道是哪一類錯誤、哪個區段出問題。

使用例外處理的注意事項

不要濫用 try-catch: 不要把一大段程式碼包進去，應該只針對會出錯的細節局部捕捉。
要精準指定例外類型: 不要一律抓大範圍的 Exception，應該針對特定錯誤類型。
處理後要適當回報或補救: 不要捕捉完就什麼都不做 (像空的 catch 區塊)，這樣很容易讓問題隱形化。
避免吞掉錯誤訊息: 即使處理錯誤，通常應該記錄 (log)下來，方便後續追蹤。
考慮資源清理: 像開啟的檔案、網路連線等，在例外發生時也要記得適當關閉。 (可以用 finally 或像 Python 的 with。)

為什麼有些人推崇「不要使用例外處理」？

有一派人主張「儘量避免使用例外處理」

例外是跳躍式流程 (non-linear flow)
- 例外會讓程式流程「瞬間跳離」正常的邏輯，破壞了可預期性 (predictability)。
- 在大型系統中，很難追蹤例外是從哪裡丟出來、哪裡被捕捉，導致程式難以閱讀與維護。
過度使用例外會掩蓋真正的問題
- 把錯誤包起來、不好好處理，會讓程式進入隱性錯誤狀態，看起來正常但其實已經錯了。
- 最可怕的是「以為一切正常」，實際上錯誤被靜悄悄地吞掉。
效能考量 (雖然在現代語言中不太嚴重，但在高頻率場景還是有影響)
- 例外處理 (特別是 throw/catch)通常在底層會有額外的記憶體和堆疊操作成本。
- 在需要高效即時反應的場景 (像遊戲引擎、深度循環中)盡量不靠例外。
可以用正常的 return 來處理失敗
- 一些工程師認為，應該用明確的回傳值 (如 None、error code、Result 型態)來告知失敗。
- 這樣程式流程清楚，失敗是正常的一部分流程，而不是突如其來的跳出。

這種思想的典型例子 (不用例外的風格)

像很多 C++、Rust、Go 都比較推崇這種作法: 錯誤是正常的一種結果，不需要例外。

例如 Go 語言標準寫法: Go 根本沒有傳統意義的 try-catch，它強迫你每步都檢查 err，讓錯誤顯式出現在流程中。

f, err := os.Open("file.txt")
if err != nil {
    // 正常檢查錯誤，不靠 try-catch
    log.Fatal(err)
}
defer f.Close()

小結論

小規模、單純邏輯的系統: 可以用例外處理，乾淨又直覺。
大型、強調高穩定性系統 (比如伺服器、嵌入式系統): 傾向少用或不用例外，錯誤要明確回傳。

總結

例外處理是現代程式設計中不可或缺的機制，它讓程式能優雅地面對錯誤，提升穩定性與可維護性。然而，例外本身也帶來流程跳躍、錯誤掩蓋、以及效能隱憂等問題。因此，在撰寫程式時，我們應該理解例外處理的精神，而非盲目使用或一味避免。根據系統規模、錯誤的重要性與可預期性，靈活選擇「例外」或「正常回傳錯誤」的方式，才能寫出既穩健又可讀的程式。最終，錯誤處理本身就像程式設計的一面鏡子——反映出我們對系統風險、可預期性與設計哲學的深刻理解。