0

これまでのところ、(通常) アサートするときはスローも行う必要があることを学びました。最初はそれが正しいかどうか確信が持てず、理にかなって1、その後、この回答が検証されました。

私が抱えている問題は、コードの繰り返しが発生することです（少なくとも契約を介して）。null または空白を使用できない名前フィールドの例を次に示します。

 public String Name
 {
     get { return _name; }
     set
     {
         Contract.Requires(String.IsNullOrWhiteSpace(value) == false, "Names cannot be null or whitespace.");
         if (String.IsNullOrWhiteSpace(value))
             throw new ArgumentException("Names cannot be null or whitespace.");

         _name = value;
     }
 }

明らかに、条件とエラー メッセージの両方が繰り返されます。どのように処理すればよいですか？1 つのプロパティでは管理可能ですが、複数のフィールドを持つクラスでは散らかっています。

追加情報

（デバッグでアサートし、リリースでスローする）を使用することを考えContract.Requires<TException>ましたが、条件（コード）は例外のメッセージになり、ユーザーに表示される可能性が最も高くなります（ユーザーはおそらく知りたいと思うでしょう）なぜ彼のプログラムがクラッシュしたのか、実際のコードは示したくありません)。次に例を示します。

static void MyFunction(Boolean youCanSeeMyCode = false)
{
    Contract.Requires<Exception>(youCanSeeMyCode, "(This is the exception's message)");
}

...

try
{
    MyFunction();
}
catch (Exception ex)
{
    MessageBox.Show(ex.Message, "Error");
}

エラーメッセージ

助言がありますか？私は途方に暮れています。

1 assert だけを使用していて、気付いていないバグがどこかに残っている場合、リリース ビルドはすべてが順調であるかのように続行され、地獄が解き放たれる可能性があるため、これは理にかなっています。

4

1 に答える 1

2

あなたがリンクした答えは aboutDebug.Assertです。これは、リリース ビルドではデフォルトでオフになっています。私はその考えが好きではありませんでした.運転を学んでいるときにのみシートベルトを着用する価値があり、高速で運転しているときはそうではないと言っているようなものです.

(個別の明示的な throw ステートメントは使用しない)だけContract.Requiresを使用し、リリース ビルドでも前提条件がチェックされるようにプロジェクトを構成することをお勧めします。ユーザーに表示されるメッセージに関する懸念は、ここで対処する必要はありません。一般的な例外処理で対処する必要があります。ユーザーに例外メッセージを表示したくない場合は、表示しないでください...ただし、ログに記録してください。例外をエンドユーザーにとって意味のあるものにしようとするべきではありません...それは彼らの目的ではありません。

于 2013-03-01T15:16:05.060 に答える