2

大まかな調査では、エラーは if-then-else 構文を使用して処理できると思います。次のように簡単な例を見てみましょう。

ゼロ除算は

int x=1;
int y=0;
if(y==0)
    Console.WriteLine("undefined");
else
    Console.WriteLine("x/y={0}",x/y);

try-catch に相当するものを置き換える

int x=1;
int y=0;
try
{
    Console.WriteLine("x/y={0}",x/y);
}
catch
{
    Console.WriteLine("undefined");
}

try-catch を if-then-else に置き換えることができる場合、どれが推奨されますか?

4

10 に答える 10

5

制御の流れに例外を使用しないでください。例外は「例外的」であるべきです。一部のデータ検証のルールを知っている場合は、通常の if/then/else を使用する必要があります。

複数の方法で失敗する可能性のある操作 (データベースへの接続など) を実行している場合は、その操作を try-catch ブロックに入れて、それに応じて動作する必要があります。

残念ながら、何かを「例外的」として扱うかどうかの選択は、デザイナーの判断に委ねられます。

編集: また、ロギングの力を過小評価しないでください。ロギング フレームワークを使い始めてから、デバッグにかかる​​時間が半分になりました。

于 2013-09-20T04:34:38.460 に答える
3

いくつかの予期しないエラーがあり、これが try-catch ステートメントを使用する場所であるという単純な理由によるすべてのエラーではありません。ただし、誤動作を防ぐために try-catch を使用することはお勧めできません。

さらに、処理方法を知っている、または処理できる例外のみをキャッチします。そうしないと、すべての例外をやみくもに飲み込んでしまい、アプリケーションのデバッグが非常に困難になります。

ただし、例外を処理する方法がわからないが、アプリケーションがコードのその部分のエラーから回復できることがわかっており、未処理の例外が原因でアプリケーションがクラッシュするのを避けたい場合は、 try-catch ブロックを使用しますが、例外の詳細をログに記録することもお勧めします。

于 2013-09-20T04:27:58.477 に答える
1

ブロック TRY..CATCH は IF..ELSE を置き換えません! それらは2つの異なるものです。

TRY..CATCH ブロックはエラーがあればそれをキャッチしますが、IF..ELSE は条件です。最初の条件が false の場合、ELSE 部分が実行されます。

ただし、ベスト プラクティスは 2 つを使用することです。

try
{
  if(y==0) 
  {
    Console.WriteLine("undefined");
  }
  else
  {
    Console.WriteLine("x/y={0}",x/y);     
  }
}
catch (Exception ex)
{
    Console.WriteLine("Error" + ex);
}

この場合、たとえばyがDateとして宣言されている場合、 (y==0) は評価されないため、条件はエラーをスローします。したがって、CATCH に送られ、変換タイプのエラーがスローされます。

一方、yがintとして宣言されている場合(例のように)、評価エラー (y==0) がないため、IF..ELSE ブロックが実行されます。

于 2013-09-20T04:26:55.623 に答える
1

両方を使用できます。

try catch がないと、コードがスローする特定のエラーを見つけるのが難しくなります。

try
{
    int x=1;
    int y=0;
    if(y==0)
    Console.WriteLine("undefined");
    else
    Console.WriteLine("x/y={0}",x/y);
}
catch
{
    Console.WriteLine("undefined");
}

よろしくお願いします

于 2013-09-20T04:28:34.707 に答える
1

コンソールにデータを吐き出すだけでエラーを伝えたいとは思わないからです。それは通常、最後の手段です。

通常、構造化されたエラー処理システムを開発します。このような構造化システムの注目すべき機能の 1 つは、関数またはプロシージャの呼び出し元にエラー状態を伝える機能です。この場合、呼び出し元が例外的な状況が存在する可能性があることを認識しており、呼び出し先からのこのエラー通信に対処する準備ができている場合は、そのように処理されます。

ただし、例外には特別なプロパティがあり、キャッチされない限り存在し続け、「シグナル」、エラーが表すエラーが処理されるまで、呼び出し元のチェーンをどんどんバックアップします。

多くの場合、エラー (例外) はコンソールに何も送信せずにキャッチされ、処理 (処理) されます。

アップチェーンの伝播例外システムは、構造化されたエラー処理を提供する、コンパイラーに組み込まれた構文的にクリーンな方法を提供します。

エラーコードまたはシグナルもこの目的に使用できますが、構文的にはそれほどスムーズではなく、エラー処理コードがたくさんあるため、コーディングに多くの痕跡が残ります。例外は、コンパイラとランタイムを使用してエラー コードの状態を自動的に追跡することにより、絶対に必要な場合を除き、エラー処理を隠そうとします。

于 2013-09-20T04:36:26.470 に答える
1

ケースの try キャッチは、if ステートメントと同じロジックを処理しません。暗黙のうちにそうであると仮定するだけです。y == 0 は、発生する可能性がある唯一のエラーが y が 0 のときだけであると仮定することとはまったく異なります。したがって、基本的に、プログラマーは何が分岐コードを引き起こすのかを確実に知りません。フロー制御に try-catch を使用することは「最小の驚きの原則」に違反すると述べているこの記事も参照してください:通常の制御フローとして例外を使用しないのはなぜですか?

于 2013-09-20T06:28:04.813 に答える
1

これに加えて、C# や多くの言語でこれが悪い習慣である重要な理由をもう 1 つ追加したいと思います。

遅いです！

早い段階でフロー制御に try catch を使用していた状況があり、キャッチを処理するのに約 15 ミリ秒かかりました。それを if-then ステートメントに書き直すと、else (キャッチ）。Python などの他のいくつかの言語は、try catch で非常に効率的であり、C# では決して行われない独自の方法でそれらを使用できます。

于 2013-09-20T04:42:08.980 に答える