1

単純な議論のスレッドで終わらないように、質問を試みます。

最近、C# でコーディングされたアプリケーションに飛び込んで、例外メカニズムを発見しています。そして、私は次のようないくつかの悪い経験をしました

// _sValue is a string
try
{
    return float.Parse(_sValue);
}
catch
{
    return 0;
}

私はそれを次のように変更しました：

float l_fParsedValue = 0.0f;
if (float.TryParse(_sValue, out l_fParsedValue))
{
    return l_fParsedValue;
}
else
{
    return 0;
}

結果、Visual Studio の出力に次のようなメッセージが殺到しなくなりました

最初のチャンス System.FormatException blabla

「-」のような文字列がスニペットに到着したとき。2番目のスニペットを使用する方がクリーンだと思います。

さらに一歩進んで、「この try-catch でやりたいことは何でもします。何か問題が発生した場合は、catch します。」というように、例外があまりにも頻繁に使用されていることをよく見てきました。

悪い誤解にとらわれないようにするために、これらの例外をいつどのように使用するか、およびいつ古い学校の「if...else」に固執するかを明確に定義するのを手伝ってほしい.

よろしくお願いします。

4

6 に答える 6

5

例外的なケースでは、例外をスローする必要があります。つまり、予期せぬことが起こったときです。関数が定期的に例外をスローすると予想される場合、それは設計が悪い可能性が最も高いです。

TryParseあなたの例では、例外が頻繁に発生するように見えるので、それがより良いことは非常に明らかです。

しかし、たとえばファイルを解析するときは、ほぼ常に有効であると期待しています。そのため、通常は例外を使用してキャッチし、キャッチした例外を内部例外としてParse生成します。InvalidDataExceptionたとえスタイルが悪いとしても、通常は解析コードを大幅に簡素化します。

Eric Lippers のブログ エントリをお勧めします: Vexing exceptions

于 2011-05-31T08:11:00.410 に答える
2

Parse()/の場合はTryParse()、例外を待たずに TryParse を使用して、誤った入力に対して自分で対処することをお勧めします。

于 2011-05-31T08:11:43.327 に答える
2

例外は、フロー制御ではなく、例外的な動作に使用する必要があります。基本的なガイドラインは、通常のプログラム フローで定期的に例外が発生する場合は、何か間違ったことをしているということです。

ただし、try { } catch { }プレゼントを持っているだけでパフォーマンスが低下するわけではないことに注意してください。例外が実際にスローされ、スタック トレースを計算する必要がある場合にのみ、(場合によっては非常に深刻な) パフォーマンスの低下が見られます。

于 2011-05-31T08:12:51.760 に答える
1

通常の処理の一部として例外を使用するプログラムは、古典的なスパゲッティ コードの可読性と保守性の問題をすべて抱えています。

— アンディ・ハントとデイブ・トーマス

例外をいつどのように使用するかについて、単純な正解はないと思います。作業しているアプリケーションのアーキテクチャやその他の要因によって異なります。

8.3章を読むことをお勧めします。エラー処理テクニックと8.4. コード完全本の例外。

于 2011-05-31T09:00:44.313 に答える
1

これまで深く検討されていないもう 1 つの点は、例外にはコストがかかるということです。それらはプログラム内の通常の制御の流れを覆し、その結果、リソースがいくらか使用されます。

簡単なテストは、元の float.Parse コードを無効なデータでループするプログラムを作成し、実行にかかる時間を TryParse バージョンと比較することです。小さいながらも顕著な違いがあります。

例外に関する決定を下すときに心に残るスニペットは、次の記事からのものです。

ほぼルール＃1

例外をスローする必要があるかどうかを判断するときは、throw ステートメントによってコンピューターがビープ音を 3 回鳴らし、2 秒間スリープ状態になると仮定します。そのような状況でまだ投げたい場合は、それを選択してください。

于 2011-05-31T08:39:40.293 に答える
0

ああ、それが簡単だったらいいのに！しかし、残念ながら、いつ例外を使用するかの決定は、多くの場合、そうでない場合よりも主観的なものです。それでも、使用できるガイドラインがあります。たとえば、Microsoft には.

全体として、例外をスローするための経験則は、関数が本来の機能を実行できない場合にのみ例外をスローすることです。基本的に、各関数にはコントラクトがあります。入力値の有効な範囲と出力値の有効な範囲があります。入力値が無効な場合、または期待される出力値を提供できない場合は、例外をスローする必要があります。

ここには滑りやすい点があることに注意してください - (ユーザー入力の) 検証エラーも例外としてスローされるべきですか? 一部の学派はノーと言い (Microsoft を含む)、一部はイエスと言う。あなたの電話。それぞれのアプローチには利点と欠点があり、コードをどのように構成するかはユーザー次第です。

例外をキャッチするための経験則は、処理できる例外のみをキャッチする必要があるということです。さて、これも滑ります。エラーメッセージをユーザーに表示して「処理」していますか? しかし、それが悪名高いまたはの場合はどうなりStackOverflowExceptionますOutOfMemoryExceptionか? その場合、ほとんど何も表示できません。また、システム全体が使用不能な状態になる可能性がある例外は、これらだけではありません。もう一度 - あなたの電話。

于 2011-05-31T08:22:44.177 に答える