Rust 開發者們正在討論一個名為 Stack Error 的新錯誤處理庫，該庫旨在彌合流行庫 Anyhow 和 Thiserror 之間的差距。社群討論揭示了關於 Stack Error 在除錯和錯誤追蹤方面的有趣見解，特別是其對檔案和行號資訊的使用。
track_caller 可能取代宏來獲取位置資訊
圍繞 Stack Error 最有見地的討論之一是關於其檔案和行號追蹤的實現。目前，Stack Error 使用 stack_msg! 和 stack_err! 等宏來捕獲錯誤訊息的位置資訊。然而，一位社群成員指出了一個可能更優雅的解決方案：
「如果宏的存在只是為了獲取檔案和行資訊，你可以透過使用
#[track_caller]函式結合std::panic::Location來獲取相同的資訊。」
這一建議強調了 Stack Error 如何透過利用 Rust 內建的位置追蹤功能而不是依賴宏來簡化其實現。該庫的作者對這一見解做出了積極回應，表示他們之前不瞭解 track_caller，並將研究實現這種方法，這可能會完全消除對宏的需求。
錯誤顯示實現的擔憂
討論中提出的另一個技術要點涉及錯誤應如何顯示。一位社群成員指出，Stack Error 當前的錯誤顯示方法可能會導致問題：
「Display 實現真的不應該包含其源。錯誤的標準處理期望錯誤僅透過 Display 列印自身，因為遞迴遍歷源並列印它們是很常見的，所以如果 Display 也列印源，那麼你就會重複輸出。」
這一反饋解決了 Rust 錯誤處理中一個微妙但重要的方面——錯誤自身訊息與其源鏈的分離。建議是將源資訊保留在 Debug 實現中，而不是在 Display 中，這與 Rust 生態系統中的標準做法一致。
與現有錯誤庫的比較
社群討論還包括與其他錯誤處理庫如 SNAFU 和 Error Stack 的比較。Stack Error 的作者解釋說，雖然 SNAFU 結合了 Anyhow 和 Thiserror 的特性，但 Stack Error 的區別在於提供：
- 錯誤程式碼和 URI，用於執行時錯誤處理，無需字串比較
- 透過堆疊錯誤訊息建立的偽堆疊
- 錯誤訊息用於除錯而非執行時錯誤處理的理念
這些比較揭示了 Rust 錯誤處理生態系統的持續演變，不同的庫採用各種方法來解決類似的問題。
Stack Error 目標
- 提供類似於 Anyhow 的人體工程學
- 建立有助於除錯的資訊豐富的錯誤訊息
- 提供便於執行時錯誤處理的型別化資料
Stack Error 的主要特點
- 在錯誤訊息中跟蹤檔案和行號
- 支援錯誤程式碼以便於執行時錯誤處理
- 訊息堆疊以提供豐富上下文的錯誤資訊
- 與
std::error::Error特性相容，便於庫開發 - 提供簡化錯誤建立和處理的宏
相比 Anyhow 在庫開發中的優勢
一些評論討論了 Stack Error 與流行的 Anyhow 庫的關係。雖然一些使用者表達了對 Anyhow 簡潔性的偏好，但其他人指出了 Stack Error 在庫開發中的優勢。強調的關鍵區別是，與 Anyhow 的錯誤型別不同，Stack Error 實現了 std::error::Error 特性，使其適用於庫開發而不僅僅是應用程式程式碼。
這使 Stack Error 有可能填補 Rust 生態系統中的一個重要空白——提供 Anyhow 的人體工程學與 Thiserror 的庫相容性。
總之，Stack Error 代表了 Rust 錯誤處理領域的一個有趣發展。社群反饋提出了幾種庫可能演變的方式，特別是關於位置追蹤和錯誤顯示等實現細節。隨著作者採納這些反饋，Stack Error 可能成為 Rust 開發者工具箱中的寶貴補充，特別是對於那些需要既好的除錯資訊又需要執行時錯誤處理能力的庫開發者。
參考：Stack Error