1

ライブラリを作成するのはこれが初めてなので (複数のゲームで使用するため)、適切なプログラミング プラクティスとして、コードにコメントを付け、XML の概要を追加し、このライブラリのユーザーが何か間違ったことをしたときに例外処理を使用する必要があると思います。多くの .NET クラスで (ユーザーはおそらく私または私のチームメイトです)

これは、作成時に配列のサイズを決定する必要がある NoteRow クラス (ちなみに、私は音楽ゲームを開発しています) のコンストラクターです。

bool[] l1NoteData;
public NoteRow(int numberOfNotes)
{
     this.l1NoteData = new bool[numberOfNotes];
}

これで、l1NoteData 配列のブール値を切り替えるこのメソッドができました。

public void toggleNote(uint index)
{
     l1NoteData[index] = !l1NoteData[index]
}

したがって、ここで防御的なプログラミングとして、インデックス (このクラスのユーザーが指定する、私またはおそらく私のチームメイト) が、このクラスの作成時に指定された範囲外にあるかどうかを確認したいと思います。

私は多くのスロー例外とアサートとリターンブールなどを読みましたが、まだ混乱していて選択できません。ここに私の懸念があります:

  • インデックスが l1NoteData.length を超えているかどうかを確認するために 'if' ステートメントを配置する必要があります。(IndexOutOfRangeException) もしそうなら、スローされた例外の使用は何ですか? 何か問題が発生した場合、とにかくデフォルトの例外が発生しますか?
  • Assert はプログラマー向けであることを読みました。プログラマーが想定するようにコードが機能していないことをプログラマーに通知すること。また、(ユーザーが) 異常なテスト ケースを処理するために存在する例外をスローするのと比較して、テスト ケースを挿入してアサートを発生させることはできません (それが発生した場合はコードが間違っています)。これで、このライブラリのユーザーは私になります。では、私はプログラマーまたはユーザーと見なされますか? 私は、このクラスのユーザーtoggleNoteが配列の制限を超えるインデックスを呼び出して入力する可能性があるため、例外がスローされます。または、私は自分のゲームのプログラマー(このライブラリは私のゲームの一部です) として assert をそこに置く必要があるので、呼び出しを間違えないようにします。toggleNote私のゲームからの限界を超えたインデックスで。(このライブラリを使用します) アサートが発生し、修正して最終的にリリース ビルドになったため、ゲームのコードが間違っていることがわかりました。(そして、アサートコードはなくなります)
  • 上記の質問から、アサートが実行される原因となるバグがこれ以上ないことを徹底的にテストしたら、ビルドをリリースします。リリース ビルドのコードで assert が使用されないことはわかっていますが、それは本当に良いことですか? プログラムにはまだ多くのバグが残っている可能性があるため、ユーザーがそのバグに遭遇したとき、バグをキャッチするためのアサートはもう存在しません。そのため、代わりに例外を使用できる場合に使用するのは本当に良いことであり、ユーザーがその例外を発生させた場合、開発者として私はそのバグレポートを受け取って修正することができます (ただし、ユーザーは私と私の友人です)
  • 成功/失敗を示すために bool を返すよりも、例外をスローする方が 100% 優れていますか? bool を返すのに適していると思われる例は何ですか?

私はすでにこの問題で混乱しているので、混乱した英語で申し訳ありません...

4

4 に答える 4

2

初め。通常、リターンコードの前の例外の利点の1つは、例外を無視できないことです。これにより、ユースケースが得られます。ライブラリを使用するユーザー(プログラマー)が重要なことを見逃したくない場合は、例外を使用してください。2番。私は、あなたは一般的に、プログラマーとしてもユーザーとしても、ライブラリーでassertを使用しないと思います。つまり、ライブラリを使用するコードでassertを使用して、仮定が真であるかどうかを確認する必要があります。

于 2012-06-12T14:44:50.100 に答える
2

Assert はテスト用です。アサートは、本番アプリケーションでのエラー処理には使用されません

入力がユーザーからのものかどうか、エラーが予想されるかどうかなどを事前に確認する必要があります。

エラーが完全に予期しないものである場合、それが例外処理の目的です。

独自のプログラムが index パラメータを提供している場合、間違った値が渡されるとバグになります。これには例外があります。

これについていくつかの良い質問がされました

例外は本当に例外的なエラーに対するものですか?

Debug.Assert と例外

例外と C# の「if」

于 2012-06-12T14:41:19.340 に答える
2

事前チェック (関数の先頭にある単純な if ステートメント) を使用して独自の例外をスローする最大の理由は、独自の非常に詳細な例外メッセージを指定できることです。デフォルトの「Index out of array bounds」またはそれが何であれ、代わりに、明示的に「ねえ、ばか。存在しないメモを切り替えようとしました」と言うことができます。またはあなたが望むものは何でも。

独自の例外のもう 1 つのケースは、ライブラリ コードを参照する場合です。エラーを明示的にチェックすると、ライブラリのソースを閲覧しているすべての人に、これが潜在的なエラーであることが警告されます。コードで何をしたいのかを明示してください。

于 2012-06-12T14:44:25.280 に答える
1

簡単な質問を自問してください。それが起こらないようにしたいですか?

はいの場合は、メソッド エントリのインデックスを確認し、無効な場合は例外をスローします。これは、メソッド呼び出しで引数が検証される通常の方法です。

いいえの場合は、いくつかのオプションがあります。

  • System.Diagnostics.Debugまたはを使用System.Diagnostics.Traceして無効なインデックスを記録し、何もせずに黙って戻ることができます。
  • あなたはそれを無視することができ、IndexOutOfBoundsExceptionとにかくスローします。
  • 例外を停止するためにそれを防ぐことができますが、それ以外の場合はメソッドから正常に戻ります。
于 2012-06-12T14:43:41.023 に答える