開發者社群正在積極討論 eserde ，這是一個新的 Rust 庫，承諾透過同時報告多個反序列化錯誤來改進API開發。雖然這種方法為API使用者帶來了明顯的好處，但討論也揭示了人們對其實現既有熱情又有實際顧慮。
錯誤處理中的效能權衡
社群強調了 eserde 方法中一個重要的技術考量。在遇到錯誤時，該庫會對輸入資料進行兩次處理——首先使用 serde_json 的反序列化器，如果出現錯誤則使用自己的處理器。雖然在正常情況下的效能與傳統的 serde_json 實現一樣快，但在錯誤情況下處理時間至少會增加一倍。這種設計選擇在錯誤場景中優先考慮了相容性和可靠性，而非原始效能。
eserde 的關鍵考慮因素：
- 錯誤情況下的雙重反序列化
- 與現有的 serde_json 實現相容
- 更長的編譯時間（生成的程式碼量約為原來的2倍）
- 對自定義錯誤格式化的支援有限
- 不支援從不可重放的讀取器進行反序列化
實際API開發中的挑戰
開發者分享了一些令人信服的用例，展示了多重錯誤報告如何顯著改善開發體驗。社群中有一個特別突出的例子：
「我曾經參與過一個專案，後端開發者對型別的理解存在根本性問題，導致JSON陣列在為空時會改變其型別，例如從陣列變成一個空物件。」
這樣的實際場景表明，全面的錯誤反饋可以節省大量的開發時間並減少挫折感。
整合和實現方面的顧慮
社群提出了幾個關於 eserde 實現的實際問題。一個值得注意的限制涉及錯誤格式化功能。一些開發者指出，雖然像 serde_json 和 toml 這樣的庫提供了詳細的錯誤資訊用於自定義格式化（類似於 rustc 的輸出），但 eserde 目前透過將錯誤轉換為字串來簡化這一過程，這可能限制了錯誤處理和展示的靈活性。
可選欄位的爭議
關於處理部分反序列化結果的討論引起了廣泛關注。一些開發者主張應該同時返回部分結果和錯誤，而其他人則強調保持嚴格型別安全的重要性。社群指出，現有的 serde 功能，如可選欄位和預設值，已經提供了在適當情況下處理缺失或部分資料的機制。
未來影響
儘管存在一些限制，社群普遍認為 eserde 對API設計來說是一個很有前途的發展。該庫的全面錯誤報告方法可以顯著減少除錯API負載時通常需要的來回溝通，不過開發者在採用之前應該仔細考慮效能影響和使用場景。