可以安全地假设从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中文网其他相关文章！
