可以安全地假設從 strconv.Parse* 函數傳回的任何錯誤一定是由於錯誤的輸入資料造成的嗎？

可以安全地假設從strconv.Parse函數傳回的任何錯誤一定是由於錯誤的輸入資料造成的嗎？這個問題涉及了對於strconv.Parse函數的錯誤處理的理解。通常情況下，strconv.Parse函數傳回的錯誤確實是由於輸入資料不符合預期格式而導致的。然而，也有一些特殊情況需要考慮。一些錯誤可能是由於輸入資料的類型錯誤，例如將字串轉換為整數時，字串中包含了非數字字元。此外，還有一些邊界情況，例如整數溢位或浮點數精度遺失，也可能導致錯誤的回傳值。因此，對於從strconv.Parse函數傳回的錯誤，我們不能完全假設是由於錯誤的輸入資料造成的，而是需要綜合考慮其他可能的因素。

問題內容

在最近的一次程式碼審查中，審查者對我如何處理從 strconv.ParseUint() 傳回的錯誤提出了疑問。此函數被記錄為傳回轉換後的 uint 值和 *strconv.NumError 具體類型的錯誤。文件提到了可以傳回的該類型的兩個哨兵錯誤（ErrSyntax 和 ErrRange），這兩個錯誤都意味著向其提供了錯誤資料。根據該函數的接口，也可能出現任何其他錯誤。

對於我的用例，我需要知道我擁有的字串值是否值得轉換為 uint。如果 ParseUint 回傳錯誤，而且它是哨兵錯誤之一，那麼我得到了答案。但如果返回的錯誤不是這些，那麼我返回它並停止執行。我的審閱者斷言，我應該假設從ParseUint 返回的任何錯誤意味著我給了它錯誤的數據，並且不需要檢查哨兵錯誤，沒有理由檢查哨兵錯誤，也不會傳回該錯誤（在我的用例中）。他們連結到 go 標準庫中的一個範例，其中來自 ParseUint 的錯誤被視為對錯誤輸入資料的檢查並且從未返回，並表示有很多這樣的範例。

雖然我當然可以理解，一定存在一種演算法，只要提供良好的數據和足夠的資源，就始終能夠計算出所需的結果，但現實世界並不總是符合理論理想。我在圖書館的文檔中找不到任何內容表明它不會也永遠不會因錯誤資料以外的任何其他原因而返回錯誤。標準庫有一個或可能有很多這樣的例子，一方面令人放心，另一方面令人恐懼，介於「兩個錯誤不能構成正確」和「他們正在這樣做，所以對我們來說一定是安全的”之間在這種情況下也這樣做。

這只是圖書館文件缺少一句話的情況嗎？或者當這兩個錯誤都不是時返回錯誤是好的嗎？我該如何推理？

解決方法

是的，可以安全地假設 strconv.ParseXXX 函數的錯誤是由於錯誤的輸入資料造成的。

從您提到的文件頁面：

我閱讀此內容的方式是「strconv.ParseXXX 中的任何錯誤都是 NumError ，並且可能是由於無效數字或位元大小範圍錯誤」。我的理解是，godocs 試圖盡可能完整地概述函數呼叫的期望範圍。

因此，我認為可以安全地假設這些是您可能會看到從 strconv.ParseXXX 函數返回的唯一錯誤。如果有其他東西回來，我會認為它是一個文件錯誤。

回答您的最後一個問題：您在標準函式庫呼叫此函數時觀察到的模式是正確的。傳回整個錯誤並讓呼叫者決定如何處理它。哨兵錯誤旨在幫助您了解出了什麼問題，並代表了這些函數可能出現的錯誤的全部範圍。

以上是可以安全地假設從 strconv.Parse* 函數傳回的任何錯誤一定是由於錯誤的輸入資料造成的嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！