c# - ガード句を使用するか、例外をキャッチする方が良いですか?

Question

ガード句で例外を防ぐか、例外をキャッチする方が良いですか? ベストプラクティスはありますか? 2 つの方法論の長所と短所は?

たとえば、これはより良いです：

try
{ 
    param=myArray[3];
}
catch (IndexOutOfRangeException e)
{
    do something...
}

またはこれ：

if(myArray.Length < 4)
{
    do something...
}
else
{
    param=myArray[3];
}

回答ありがとうございました:)

score 19 · Accepted Answer

ガード句で例外を防ぐか、例外をキャッチする方が良いですか?

範囲外のインデックスなどの「骨の折れる」例外の場合は、常に前者です。

「外生的な」例外の場合は、常に後者です。

2 つの方法論の長所と短所は?

骨の折れる例外の場合、後者の短所しかありません。彼らです：

例外は、テストに比べて非常にコストがかかります。
例外は、非常にまれな制御フローの状況をモデル化することを目的としています。範囲外のインデックスにアクセスする可能性があるのが正常な場合は、例外ハンドラーを作成しないでください。
例外が処理された場合でも、例外は「最初のチャンス」の例外としてリスナーに報告されます。多くのシステム (ASP など) は、最初の例外をリッスンし、それらをすべてログに記録し、多くの例外を生成するコンポーネントをバグのあるものとして扱います。(以前、ASP の共通コードパスに意図的に初回例外を導入したことがありますが、翌日にはそのことを耳にしました。バグのあるサブシステムテストはおかしくなってしまいました。)
私が「骨の折れる」例外と呼んでいるいくつかの例外があります。null デリファレンス、範囲外のインデックスなどです。これらは回避しやすく、明らかに危険な障害を示すため、常に致命的なバグとして扱う必要があります。処理されません(「ハンドラ」がプロセスをシャットダウンする前にログに記録していない限り)。バグを処理せず、バグを排除します。

最後に、このテーマに関する私の記事を読んでください。

score 18 · Accepted Answer

ガード句を使用する - 例外をキャッチすると高いランタイムコストが発生します。一般に、読みやすさを向上させるには、通常の制御フローではなく、エラー状態に対してのみ例外を使用する必要があります。

score 5 · Accepted Answer

ガード条項。制御フローにtry/を使用することは決してありません。catch例外のキャッチはコストがかかるため、できる限り回避する必要があります。

score 4 · Accepted Answer

例外を防止できる場合は、防止します。いつも。

例外のキャッチと処理はコストがかかるため、通常の制御フローには使用しないでください。ガードは安価で簡単です。

4 に答える 4