Is it safe to assume that any errors returned from strconv.Parse* functions must be due to bad input data?

Is it safe to assume that any error returned from the strconv.Parse function must be due to bad input data? This question involves the understanding of error handling of the strconv.Parse function. Typically, the error returned by the strconv.Parse function is indeed caused by the input data not being in the expected format. However, there are some special circumstances that need to be considered. Some errors may be due to the wrong type of input data, such as when converting a string to an integer and the string contains non-numeric characters. Additionally, there are edge cases, such as integer overflow or loss of floating point precision, that can also result in incorrect return values. Therefore, for errors returned from the strconv.Parse function, we cannot completely assume that they are caused by incorrect input data, but need to consider other possible factors.

Question content

During a recent code review, the reviewer raised questions about how I handle errors returned from strconv.ParseUint(). This function is documented to return the converted uint value and the *strconv.NumError specific type of error. The documentation mentions two sentinel errors of this type that can be returned (ErrSyntax and ErrRange), both of which mean that bad data was supplied to it. Depending on the interface of the function, any other error may also occur.

For my use case, I need to know if the string value I have is worth converting to a uint. If ParseUint returns an error, and it's one of the sentinel errors, then I have the answer. But if the error returned is none of these, then I return it and stop execution. My reviewer asserted that I should assume that any error returned from ParseUint means I gave it the wrong data, and that there is no need to check for sentinel errors, there is no reason to check for sentinel errors, Also the error is not returned (in my use case). They link to an example in the go standard library where an error from ParseUint is treated as a check for bad input data and never returned, and say there are many such examples.

While I can certainly understand that there must be an algorithm that can always compute the desired result given good data and enough resources, the real world does not always match the theoretical ideal. I can't find anything in the library's documentation that states that it does not and will never return an error for any reason other than bad data. The standard library has one or probably many examples of this, which is reassuring on the one hand and terrifying on the other, somewhere between "two wrongs don't make a right" and "they're doing it this way, so it must be safe for us The same is done in this case.

Is this just a case of the library documentation missing a sentence? Or is it good to return an error when it is neither of these two errors? How should I reason?

Solution

Yes, it is safe to assume that the error in the

strconv.ParseXXX function is due to incorrect input data.

From the documentation page you mentioned:

The way I read this is "Any errors in strconv.ParseXXX are

NumError and may be due to invalid numbers or bit size range errors". My understanding is that godocs try to outline as completely as possible the expected scope of a function call.

Therefore, I think it's safe to assume that these are the

only errors you may see returned from the strconv.ParseXXX function. If something else comes back, I'd consider it a documentation bug.

To answer your last question: the pattern you observed when calling this function from the standard library is correct. Return the entire error and let the caller decide what to do with it. Sentinel errors are designed to help you understand what went wrong and represent the full range of errors that can occur with these functions.

The above is the detailed content of Is it safe to assume that any errors returned from strconv.Parse* functions must be due to bad input data?. For more information, please follow other related articles on the PHP Chinese website!