Hacker News
This article explores how Go 1.20 and 1.21 introduced cause-tracking functions to the context package, solving the long-standing issue of vague context canceled errors by allowing developers to attach specific reasons to cancellations.
AI 生成摘要
這篇文章探討了 Go 1.20 與 1.21 如何在 context 套件中加入原因追蹤功能，透過允許開發者為取消操作附加特定原因，解決了長期以來 context canceled 錯誤訊息過於模糊的問題。
在 Go 語言的開發實踐中，開發者經常面臨 Context 被取消或逾時，卻無法得知具體原因的困境。Go 1.20 與 1.21 版本分別引入了 WithCancelCause 與 WithTimeoutCause，允許開發者為 Context 取消附加自定義的錯誤原因，以解決長期以來僅能看到 context canceled 或 context deadline exceeded 等模糊訊息的痛點。
針對這項新特性，Hacker News 的社群討論呈現出兩極化的反應。支持者認為 Context 的取消與傳播機制是 Go 語言最強大的功能之一，甚至有開發者表示這是他熱愛使用 Go 編寫控制平面的主因。討論中也橫向對比了其他語言的實現，例如 C# 的 CancellationToken、Java 21 的結構化併發，以及 Kotlin 的協程機制。其中，Haskell 的非同步異常處理被譽為該領域的標竿，因為它能中斷任何純函數或 IO 操作，且不帶語法負擔，相較之下 Go 的實現顯得較為繁瑣。
然而，社群中也存在不少批評聲音，主要集中在 Go 語言日益增加的樣板代碼問題。部分開發者認為，為了獲取取消原因而必須手動傳遞 Context 並撰寫大量錯誤處理邏輯，是一種對語言設計缺陷的妥協。有留言指出，這反映了 Go 團隊在追求簡單性時，將解決問題的負擔轉嫁給了開發者，導致開發者必須像「對抗語言」一樣工作。甚至有觀點建議，Context 與錯誤處理應該像隱含變數一樣由編譯器處理，而非強迫開發者在每個函數簽名中顯式宣告。
此外，關於錯誤處理的哲學爭論也隨之展開。一些開發者堅信顯式的錯誤處理優於傳統的異常機制，認為這能讓代碼流向更易於追蹤；但反對者則認為，當 99% 的錯誤處理只是簡單地包裹並回傳時，這種顯式性就變成了無意義的雜訊。對於本次新增的 Cause API，雖然解決了生產環境中難以調試的問題，但其與 defer cancel() 互動時可能導致原因遺失的細節，也被視為另一種容易踩坑的設計陷阱。
在討論過程中，開發者們分享了數個相關的技術資源。針對 JavaScript 環境，有開發者推薦了 context 輔助函式庫，旨在為 JS 提供類似 Go 的 Context 開發體驗。在結構化併發方面，Kotlin 官方文件的 Coroutines basics 提供了關於父子任務取消機制的詳細說明。此外，Go 官方提案 #26356 與 #51365 則記錄了這項功能從初步構想到最終實作的完整歷史背景與社群討論過程。