プロパティのゲッターまたはセッター内から例外をスローすることが適切なのはいつですか? 適切でないのはいつですか? その理由は? 主題に関する外部ドキュメントへのリンクがあると便利です... Google で検索しても驚くほど少ない結果しか出てきませんでした。
ベストアンサー1
マイクロソフトは、プロパティの設計方法に関する推奨事項を次のように公開しています。http://msdn.microsoft.com/en-us/library/ms229006.aspx
基本的に、プロパティ ゲッターは常に安全に呼び出せる軽量のアクセサーにすることを推奨しています。例外をスローする必要がある場合は、ゲッターをメソッドに再設計することを推奨しています。セッターの場合、例外は適切で許容できるエラー処理戦略であることを示しています。
インデクサーについては、ゲッターとセッターの両方が例外をスローすることが許容されると Microsoft は示しています。実際、.NET ライブラリの多くのインデクサーはこれを実行します。最も一般的な例外は ですArgumentOutOfRangeException。
プロパティ ゲッターで例外をスローしたくない理由はいくつかあります。
- プロパティはフィールドのように見えるため、プロパティが (設計上) 例外をスローできるかどうかは必ずしも明らかではありません。一方、メソッドの場合、プログラマーは、メソッドの呼び出しによって例外が予期されるかどうかを予測して調査するように訓練されています。
- ゲッターは、シリアライザーやデータバインディング (WinForms や WPF など) などの多くの .NET インフラストラクチャで使用されます。このようなコンテキストで例外を処理すると、すぐに問題が発生する可能性があります。
- プロパティ ゲッターは、オブジェクトを監視または検査するときにデバッガーによって自動的に評価されます。ここで例外が発生すると混乱を招き、デバッグの作業が遅くなる可能性があります。同じ理由から、プロパティで他のコストのかかる操作 (データベースへのアクセスなど) を実行することも望ましくありません。
- プロパティは、連鎖規則でよく使用されます。
obj.PropA.AnotherProp.YetAnotherこのような構文では、例外 catch ステートメントをどこに挿入するかを決定することが問題になります。
ちなみに、不動産が設計されていない例外をスローするからといって、例外をスローしないというわけではありません。例外をスローするコードを簡単に呼び出すことができます。新しいオブジェクト (文字列など) を割り当てるという単純な操作でも、例外が発生する可能性があります。常に防御的にコードを記述し、呼び出すものすべてから例外が発生することを想定する必要があります。