strconv.Parse 関数から返されるエラーは、不正な入力データが原因であると考えても問題ありませんか?この質問には、strconv.Parse 関数のエラー処理の理解が含まれます。通常、strconv.Parse 関数によって返されるエラーは、入力データが予期された形式ではないことが原因で発生します。ただし、考慮する必要がある特殊な状況がいくつかあります。一部のエラーは、文字列を整数に変換し、その文字列に数値以外の文字が含まれている場合など、入力データのタイプが間違っていることが原因である可能性があります。さらに、整数のオーバーフローや浮動小数点精度の損失などの特殊なケースがあり、これも誤った戻り値を引き起こす可能性があります。したがって、strconv.Parse 関数から返されたエラーについては、誤った入力データが原因であると完全に想定することはできませんが、考えられる他の要因を考慮する必要があります。
最近のコード レビュー中に、レビュー担当者から、strconv.ParseUint()
から返されたエラーの処理方法について質問がありました。この関数は、変換された uint 値と *strconv.NumError
特定の種類のエラーを返すように文書化されています。ドキュメントには、このタイプの 2 つのセンチネル エラーが返される可能性があることが記載されています (ErrSyntax
と ErrRange
)。どちらも不正なデータが提供されたことを意味します。関数のインターフェイスによっては、他のエラーが発生する場合もあります。
私のユースケースでは、手持ちの文字列値が uint に変換する価値があるかどうかを知る必要があります。 ParseUint
がエラーを返し、それがセンチネル エラーの 1 つである場合、答えは見つかります。ただし、返されたエラーがこれらのいずれでもない場合は、エラーを返し、実行を停止します。私の査読者は、ParseUint
から返された エラーは、間違ったデータを与えたことを意味すると考えるべきであり、センチネル エラーをチェックする必要はなく、センチネルをチェックする理由はない、と主張しました。エラーも返されません (私の使用例では)。これらは、ParseUint からのエラーが不正な入力データのチェックとして扱われ、返されない go 標準ライブラリの例にリンクしており、そのような例はたくさんあると述べています。
これは単にライブラリのドキュメントに一文が欠けているだけなのでしょうか?それとも、これら 2 つのエラーのどちらでもない場合にエラーを返すのが良いのでしょうか?どのように推論すればよいでしょうか? 解決策はい、
strconv.ParseXXX関数のエラーは入力データが正しくないことが原因であると考えて間違いありません。
これを読むと、「strconv.ParseXXX のエラーは
NumError であり、無効な数値またはビット サイズ範囲エラーが原因である可能性があります。」となります。私の理解では、godoc は関数呼び出しの予想範囲を可能な限り完全に概説しようとしています。
strconv.ParseXXX 関数から返される可能性のある
のみの エラーであると想定しても問題ないと思います。何か他のものが戻ってきたら、それはドキュメントのバグだと考えます。
以上がstrconv.Parse* 関数から返されるエラーは、不正な入力データが原因であると考えても問題ありませんか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。