"Error-Handling"
- 5.1 錯誤回傳與早期返回
寫出可追蹤的失敗路徑
- 5.1 異常處理策略
何時捕獲、何時拋出
- 自動攔截機制
JS window.onerror / Flutter FlutterError.onError / Python sys.excepthook — 各平台攔截未捕獲例外的機制和限制
- 5.2 返回值設計
(bool, str) 模式的應用
- 0.3 錯誤處理：把失敗路徑寫出來
理解 Go 顯式錯誤處理在服務維護中的價值
- 5.5 頂層例外處理機制
run_hook_safely 與統一錯誤基礎設施
- 0.6 Happy path 理論：錯誤路徑放哪裡
判讀集中式例外處理與顯式錯誤值各自適合的服務型態，以及 Go 為什麼選擇讓錯誤路徑留在正文
- 5.7 錯誤處理與測試在高併發服務中的角色
把錯誤路徑、測試保護與並發行為放進服務可靠性觀點
- Exception 型別綁 ErrorCategory 的建構不變式 — 以及合法需求撞上不變式的時刻
把「錯誤代碼必須屬於對應分類」做成建構期不變式，錯誤分類錯亂會變成測試失敗而不是靜默混亂；同一批修復出現三種形態——換對值、換精確值、以及改繼承逃離約束。第三種是分類學本身的訊號：一個 domain 的錯誤天生橫跨技術分類時，分類軸跟階層軸不正交。
- 宣告回歸原生 Exception、三個版本後階層重生 — 需求不死、只是換宿主
「砍掉過度設計、回歸原生」的重構把實作砍了、沒盤點實作回應的需求：錯誤要序列化、要使用者訊息、要分類路由，這些消費者還在，於是基類與階層在新架構裡原地長回來。砍之前分「有消費者的機能」與「沒有的」，口號式目標不可驗收、需求清單可以。