3

私はここでプログラムの正しい構造を理解して、すべてを容易にしようとしています。基本的に、物を「置く」場所。

例えば：

2つのクラスがあります。

クラス1がメインです。

どちらのクラスにも多くのメソッドがあります。

クラス1はクラス2のインスタンスを呼び出し、メソッドを実行します。このメソッドは値を返すことになっています。

質問1：このメソッド（クラス2）内にtry / catchブロックを含める必要がありますか？

質問2：try / catchブロックは、（クラス1の）メソッドを呼び出す場所にする必要がありますか？

try
   method();
catch
...

質問3：クラス2にあるメソッドを実行するときに、値を返す場合、「エラーコード」を返し、呼び出し元のクラスでこのコードを処理する必要がありますか？

質問4：エラーが発生し、プログラムを「停止」する必要がある場合、正しい条件が満たされた場合にのみコードが進むようにif / elseステートメントを使用する必要がありますか、それともキーワード「break」をより頻繁に使用する必要がありますか？

質問5：特に中規模から大規模のプログラムがある場合、エラーの可能性は無限に広がる可能性があります。ユーザーがプログラムを実行しているときに発生する可能性のある不明なエラーにどのように対処しますか？

4

5 に答える 5

4

例外はそれだけです：例外的です。通常のプログラムフローに例外を使用するべきではありません。（「ああ、そうだと思っていた」と言えば、それも例外ではないでしょう。）

処理が必要な場合は例外を処理します。try-catchそのブロックが成功せずに関数を存続できる場合は、そこで処理する必要があります。finally同様に、いくつかをまとめる必要がある場合は、ブロックを追加することもできます（ C＃の場合usingと同様です。コンパイルはになりますが、自分で作成するほど堅牢ではありません。指定した使い捨てオブジェクトを呼び出すだけです）。finallytry-finally.Dispose()

ただし、その関数から抜け出す必要がある場合、またはメインクラスですべて成功する必要がある一連の関数を実行している場合は、クラス1で処理を行う方がよい場合があります。

警告：すべてのルールには例外があります（ha！）。プログラムを増やすと、エラー処理をどこで行うべきかを直感的に理解できますが、多くの場合、複数のオプションがあり、明確ではない場合があります。

于 2012-08-15T13:41:35.997 に答える
3

一般的に、これらすべての質問に対する答えは「状況によって異なります」です。明らかに、あなたがする必要があることは、状況の特定の状況とそれに含まれるアプリケーションに依存します。

プラクティスの観点から、私は一般的にいくつかのルールに従います
。1.エラーコードの代わりに例外処理を使用します
。2。例外の処理方法を知っている場合にのみtry/catchを使用します。

明らかに、メソッドが何をするのか、そして例外を処理できるかどうかを知らなければ、メソッド内でtry/catchが必要かどうかを知ることはできません。

エラーコードが本当に適用できるかどうかはあなた次第です。私は一般的にそれを適用できないと考えています。しかし、時々そうかもしれません。そのような場合、発信者が常にコードを使用し、コードを渡さない場合にのみ、適用可能と見なします。「GetErrorCode」は、エラーコードが適用される可能性がある場合の良い例です。

「不明な」エラーを「処理」（つまり、補正）することはできません。推奨される方法は、例外を処理せず、不明な状態にあるため、ハンドルを正常に終了させることです。

于 2012-08-15T13:41:52.567 に答える
0

私は一般的にDavidとPeterに同意します...私が追加する1つのことは、キャッチするときにキャッチする例外に注意することです... Richterには、例外処理と例外がどのように継承されると想定されているかについての非常に興味深い章があります。対実際に実装された方法...しかし、それでも、一般的なExceptionクラスを一貫してキャッチしていることに気付いた場合、それは（IMO）怠惰であるか、少なくとも考え抜かれたものです...

ファイルの読み取り/書き込みを行っている場合は、適切なIO例外をキャッチすることをお勧めしますが、最も一般的なExceptionクラスを一貫してキャッチすると、たとえばNullReferenceExceptionがスローされ、try/catchが保護するだけだった場合に問題が発生する可能性があります。 IO例外に対して...catchブロックは（想定されていた）IO例外を修正しようとし、コードをひどく不安定な状態にする可能性があります。

さらに、元のエラーを本当に適切に処理したと確信できない限り、元のエラーを再スローし続けることに十分注意してください...ライブラリを作成して公開し、最善を尽くしていると思ったためにすべてのエラーを飲み込んだ場合は、そうすると、ライブラリを消費した誰かが何が起こっているのかをデバッグする方法がなくなります...例外もサーバーのログにスローされるため、飲み込まれたエラーがそこに到達することはありません。

一般的なエラーをキャッチすることをお勧めする1つの場所は、明らかにユーザーにYSODを表示したくないUIレイヤーですが、それでも、キャッチは後でデバッグするのに役立つロギングなどを行う必要があります。

于 2012-08-15T13:47:47.150 に答える
0

例外をキャッチしてエラーコード/ブールを返すと、次のような「矢印」コードになります。

if(Func1())
{
   if (Func2())
   {
       if (Func3())
       {
       }
   }
}

残念ながら、例外がエボラ出血熱のように扱われ、発生するとすぐに封じ込められる複雑なプロジェクトを維持しています。それは本当にコードを理解して維持するのを難しくします。

于 2012-08-15T13:49:24.217 に答える
0

これは、アプリケーションをどのように視覚化および構造化するかによって異なります。クラス1と2は同じモジュールの一部ですか、それとも異なるモジュールにありますか？一般に、モジュールは「API」を提供し、「API」の呼び出し元はエラーと例外をキャッチする必要があります。ディフェンシブプログラミングをご覧ください。

質問1：このメソッド（クラス2）内にtry / catchブロックを含める必要がありますか？

クラス2が別個のモジュールであり、例外を呼び出し元モジュールに伝播したくない場合は、はい。あなたがしたいのなら、いいえ。次に、このクラス/モジュールからスローされた例外を文書化する必要があります。

クラス1と2が同じモジュール内にある場合も、内部クラス内で例外を処理するかどうかによって異なります。

質問2：try / catchブロックは、（クラス1の）メソッドを呼び出す場所にする必要がありますか？

クラス1がそれ以上の例外をスローしないように保護したい場合は、はい。

質問3：クラス2にあるメソッドを実行するときに、値を返す場合、「エラーコード」を返し、呼び出し元のクラスでこのコードを処理する必要がありますか？

エラーコードを返す例外をスローしたい場合は、これも設計/実装の決定です。

質問4：エラーが発生し、プログラムを「停止」する必要がある場合、正しい条件が満たされた場合にのみコードが進むようにif / elseステートメントを使用する必要がありますか、それともキーワード「break」をより頻繁に使用する必要がありますか？

breakを使用するには、呼び出し元にループが必要です。

質問5：特に中規模から大規模のプログラムがある場合、エラーの可能性は無限に広がる可能性があります。ユーザーがプログラムを実行しているときに発生する可能性のある不明なエラーにどのように対処しますか？

大規模なプログラムはモジュールに分割されており、さまざまな開発者がコーディングできます。したがって、ここでは設計とインターフェースの契約が不可欠になります。

于 2012-08-15T13:52:40.090 に答える