依存関係プロパティを登録するときに、検証コールバックを受け入れるのオーバーロードをRegister使用できます。
その検証コールバックが値に対して返さfalseれた場合、依存関係プロパティへのその値の割り当ては失敗しArgumentException、無効なプロパティ値について不平を言う がスローされます。
現在、ArgumentException状況によっては適切なタイプですが、特定の状況で使用する必要がある特殊な例外タイプがいくつかあります。特に、enum型のプロパティを宣言していますが、サポートされていない値を処理する適切な方法はInvalidEnumArgumentException. さらに、そのenumプロパティを CLR プロパティとして表示するインターフェイスを実装しており、そのプロパティのドキュメント コメントでは、InvalidEnumArgumentException無効な値に対して をスローする必要があります。
私が見ている3つの解決策は次のとおりです。
- インターフェース ドキュメントを変更して、より一般的な例外タイプを許可します。これは乱雑であり、特殊な例外タイプを持ち、文書化するという目的を無効にするため、「解決策」として受け入れられないと考えています。それ以外の場合は、ドキュメントのどこにでも書いて、API ユーザーに任せて、実際にどれがスローされるかを推測および/または試すことができます。
Exception false依存関係プロパティに登録された値の検証コールバックから戻ります (したがって、ArgumentExceptionを介してプロパティ値を変更し、CLR プロパティ ラッパーのセッターでSetValueをスローすると、が発生します。これは別の理由で乱雑です。 /を呼び出す以外の独自のロジック.依存関係プロパティ自体の動作が、CLR プロパティ セッターを介してアクセスする場合とは異なる場合、一貫性がないように思われます。InvalidEnumArgumentExceptionGetValueSetValueInvalidEnumArgumentExceptionを返す代わりに、値の検証コールバックで をスローしますfalse。これが私が現在使用しているソリューションです。
私は3番目の解決策を試しましたが、うまくいくようです。唯一の欠点は、デフォルトの例外メッセージが失われることです。
私の質問は次のとおりです。値の検証コールバックからこのようにスローすると、私が認識していない副作用があり、それによって私 (または私のコード) が問題になりますか?