背景

在 Zig 程式語言中，標準的錯誤處理機制僅支援簡單的錯誤列舉（Error Sets），無法像 Rust 的 Result 或其他語言的異常機制那樣直接攜帶額外的上下文數據。本文作者分享了一種利用 union(enum) 建立診斷類型（Diagnostics）的模式，透過在函式簽名中傳遞診斷結構體指針，並結合編譯時計算（comptime）自動生成錯誤集，試圖在不增加呼叫端負擔的前提下，實現具備負載（Payload）的錯誤處理機制。

社群觀點

針對 Zig 是否應在語言層面原生支援錯誤負載，社群展開了激烈的辯論。部分開發者認為，目前缺乏原生支援是 Zig 的一大痛點，導致開發者必須自行構建複雜的診斷模式，這對新進者而言存在較高的門檻。批評者指出，這種「診斷模式」雖然可行，但在人體工學上顯得相當臃腫，且由於缺乏官方統一的標準實踐，許多函式庫最終選擇直接吞掉有用的調試資訊，導致生態系中的錯誤報告品質參差不齊。他們呼籲官方應將這類模式納入標準庫並提供文件指引，而非讓開發者在綠地開發階段反覆糾結於實作細節。

然而，支持現狀的觀點則認為，Zig 的設計哲學在於顯式處理與避免隱含的記憶體分配。若要讓錯誤能攜帶任意大小的負載，往往需要隱含的分配機制，這違背了 Zig 的核心原則。支持者強調，透過現有的語言特性，如傳遞指針或使用選項結構體，已經能達成極具彈性的錯誤處理。對於他們而言，Zig 的「人體工學」不在於減少打字量，而是在於如何組合簡單的語言特性來達成最優解。此外，也有開發者提醒，過度複雜的錯誤負載可能導致函式返回難以預測的大型聯集類型，這在大型專案中未必是好事。

討論中另一個有趣的維度是關於錯誤碼與報告機制的本質區別。Zig 創始人 Andrew Kelley 親自參與討論並指出，在 Zig 中，錯誤碼本質上是一種控制流構造，而非報告機制。他認為只有當錯誤會導致不同的控制路徑（例如可重試的記憶體溢出）時，才需要區分錯誤碼。至於詳細的錯誤資訊，應透過診斷模式處理。這引發了關於應用程式層級錯誤處理的討論：當錯誤發生在深層模組但需要由頂層 UI 處理（例如告知使用者哪個插件載入失敗）時，單純的錯誤碼顯然不足，這正是診斷模式發揮作用的場景。

最後，關於除錯資訊的獲取，社群也澄清了 Zig 的錯誤追蹤（Error Traces）與診斷負載的用途不同。錯誤追蹤主要用於開發者定位程式碼問題，且在特定配置下亦可在發布模式中使用；而診斷負載則是為了讓程式邏輯或終端使用者能理解錯誤發生的具體上下文。儘管對於具體實作方式仍有分歧，但社群普遍共識是：在追求高效能與顯式記憶體管理的同時，如何優雅地傳遞錯誤上下文仍是 Zig 進化過程中需要不斷磨合的課題。

延伸閱讀

• 作者提供的診斷模組程式碼（Gist）：文中提到的實作參考。
• Ziggit 討論區關於 Diagnostics 模式的搜尋結果：包含多種社群實作案例。
• Ziggy 專案中的錯誤處理實作：由社群成員 kristoff-it 提供的另一種處理模式參考。