c# - try ブロックで例外をスローすることに問題はありますか?

Question

try-catch次のようにブロックをコーディングするのは良い設計方法ですか? つまりthrow、try ブロックで a を使用してから、catch ブロックでキャッチします。

try
{
  if (someCondition){

      throw new Exception("Go the the associated catch block!");

     }
}

catch(Exception ex)
{
      logError("I was thrown in the try block above");
}

score 3 · Accepted Answer

必要な場合があります。たとえば、ado.net を使用している場合、ado.net にはすべてをとしてスローする習慣がありSqlExceptionます。これらの一部をキャッチして処理し、他の処理を残したい場合があります。別のレベルに。この場合、SqlException をキャッチし、処理できるかどうかを確認し、処理できない場合は再スローする必要があります。

score 3 · Accepted Answer

例外は、例外的な状況のためのものです。フローロジックの制御として使用するべきではありませんが、発生した場合に処理する必要があるエッジケースがある場合は、それを行っても問題はありません。

私が読んでいるデータが私が期待しているものではない場合、私は自分のコードでInvalidDataExceptionをスローしてこれを行いました。

score 2 · Accepted Answer

一般に、最短で書き込み可能な方法であれば、設計は悪くありません。ただし、excaption をスローすると、キャッチするのに通常約 1 ミリ秒かかることに注意してください。その点では、それはパフォーマンスの問題です。

score 1 · Accepted Answer

場合によっては、通常の状況で例外をスローする必要があり、一般的な例外よりも独自の例外をスローする方が適切です。

score 1 · Accepted Answer

それはあなたが達成しようとしていることに完全に依存しています。全体として、特に try-catch ブロックは遅いため、使いすぎないようにするのが最善です。try-catch ブロックがたくさんあると、コードが乱雑になり、理解が難しくなる可能性があります。

例外がスローされる理由を検討する必要があります。予期しないエラー、バグ、または予想されるエラーですか? 予想されるエラーの場合は、try-catch を使用せずに、そのエラーを回避するようにコーディングする必要があります。

score 1 · Accepted Answer

someCondition が真のエラー状態を表している場合、はい。それで問題ありません。ただし、プログラムの流れを制御するために使用しないでください。スコープを終了できるときに例外がスローされるのを見ることほど、私を夢中にさせるものはありません。また、コード内の実際の例外の適切な処理が損なわれる可能性もあります。

c# - try ブロックで例外をスローすることに問題はありますか?

6 に答える 6

Related

Reference