11

したがって、次のようなプロパティの値を検証すると聞きました。

//dummy example, let's assume that I want my value without dots
public string MyProp
{
    set
    {
        if(value.Contains('.'))
            throw new ArgumentException("Must not contain '.'", "value");
    }
}

は間違っており、避けるべきです。

しかし、以前は、これが良い方法だと言われました。カプセル化を使用できます。チェックする場所は 1 つだけです。DRY などです。

私の小さな例の何が問題になっていますか?

4

3 に答える 3

13

プロパティ セッターで例外をスローしても問題はありません。ただし、 をスローしてArgumentException、実際にプロパティの値を設定する必要があります。

private string _myprop;
public string MyProp{
    set{
       if(value.Contains('.')) throw new ArgumentException("Must not contain .");
       this._myprop=value;
    }
    get { return this._myprop; }
}

MSDN のベスト プラクティスに関する記事から:

プロパティの getter は、前提条件のない単純な操作である必要があります。getter が例外をスローする可能性がある場合は、プロパティを再設計してメソッドにすることを検討してください。この推奨事項は、インデクサーには適用されません。インデクサーは、無効な引数が原因で例外をスローすることがあります。

プロパティ セッターから例外をスローすることは有効であり、受け入れられます。

于 2013-04-08T17:38:45.390 に答える
0

SOにも同様の質問がいくつかあります。

プロパティはできるだけ軽量にする必要があります。セッターがエラーをスローした場合、これは問題ありませんが、関数に移動することを検討してください。物事は簡単に散らかってしまいます。

プロパティ ゲッターからの例外のスローを回避します。プロパティの getter は単純な操作である必要があり、前提条件はありません。ゲッターが例外をスローできる場合は、おそらくメソッドになるように再設計する必要があります。

ベスト プラクティス: プロパティからの例外のスロー

プロパティ セッターからスローする例外は?

于 2013-04-08T17:37:17.690 に答える
-2

参照してください:プロパティからの例外のスローがなぜ悪いのかについての説明と議論については、ベスト プラクティス: プロパティからの例外のスローを参照してください。

確かに、その投稿はプロパティゲッターについて語っています。

一般に、セッターは、単にプロパティによって隠されているプラ​​イベート フィールドを設定し、必要に応じて追加の処理を行うものとして消費者に認識されます。例外は予期しない動作であり、各 set ステートメントを try ブロック内に囲む必要があると想像できますか?

ガイドラインでは許容される動作かもしれませんが、開発者にとっては悪夢です。検証ロジックは別のメソッドに含めて、必要に応じてプロパティから呼び出す必要があります。

プロパティを設定するときに検証または特別な動作が必要な場合は、 set メソッドを使用する必要があります。たとえばSetMyProp(string value)、例外などにつながる可能性があるという区別が得られるためです。

WPF モデルなどのプロパティを使用している場合は、代わりに WPF の組み込みのデータ検証を利用する必要があります。

于 2013-04-08T17:32:34.823 に答える