web-dev-qa-db-ja.com

より良いこと：int.TryParseまたはtry {int.Parse（）} catch

私は知っている..私は知っている...パフォーマンスはここでの主な関心事ではなく、好奇心のためだけに、何が良いですか？

bool parsed = int.TryParse(string, out num);
if (parsed)
...

OR

try {
    int.Parse(string);
}
catch () {
    do something...
}
c#.netparsingtype-conversiontryparse
59
renanleandrof

Betterは非常に主観的です。たとえば、個人的にはint.TryParse、私はほとんど気にしないのでなぜ解析が失敗しても、解析は失敗します。しかしながら、 int.Parseは（ ドキュメント に従って）3つの異なる例外をスローできます。

  • 入力がヌルです
  • 入力が有効な形式ではありません
  • 入力にオーバーフローを引き起こす数値が含まれています

失敗の理由を気にする場合は、int.Parseが明らかにより良い選択です。

いつものように、コンテキストは王様です。

82
Fredrik Mörk

変換が時々失敗するのは例外か、変換が失敗するのはexpected and normalですか？前者の場合、exceptionを使用します。後者の場合、例外を避ける。例外は、理由により「例外」と呼ばれます。 例外状況を処理するためにのみ使用する必要があります。

39
Eric Lippert

変換が時々失敗することが本当に予想される場合、int.TryParseなど 条件付き（三項）演算子 を使用して、次のように1行できれいに：

int myInt = int.TryParse(myString, out myInt) ? myInt : 0;

この場合、TryParseメソッドが失敗すると、デフォルト値としてゼロが使用されます。

また、変換が失敗した場合にデフォルト値をnullで上書きする、null許容型に対しても非常に便利です。

19
greg84

最初。 2番目は、例外によるコーディングと見なされます。

10
George Johnston

個人的に、私は好む：

if (int.TryParse(string, out num))
{
   ...
}
8
Paddy

最初！例外によってコーディングしないでください。

あなたはそれを短くすることができます

if (int.TryParse(string, out num))

4
Mr Shoubs

まず、断然。ジョージが言ったように、2番目は例外によるコーディングであり、パフォーマンスに大きな影響があります。そして、常にパフォーマンスが問題になるはずです。

3
Madeleine

例外をキャッチするとオーバーヘッドが増えるため、TryParseを使用します。

さらに、変換が失敗した場合、TryParseメソッドは例外をスローしません。 sが無効であり、正常に解析できない場合に、例外処理を使用してFormatExceptionをテストする必要がなくなります。

here からコピーペーストされた最後の部分

2
tzup

留意すべき他のことは、例外がVisual Studioのデバッグ/出力ウィンドウに（オプションで）ログに記録されることです。例外のパフォーマンスオーバーヘッドが重要でない場合でも、デバッグ時に例外ごとに1行のテキストを書き込むと、処理が遅くなる可能性があります。失敗した整数解析操作のすべてのノイズの中で、より注目に値する例外もdrれるかもしれません。

1
Quppa