2012-02-17 7 views
1

私は、内部のバックエンドクラスを使用して、次のパブリックインターフェイス文書化例外

public interface Bar{ 
    public void DoStuff(); 
} 

internal class BarImpl : Bar{ 
    public void DoStuff(){ 
    // throw exception if invalid state 
    // do something 
    } 
} 

に質問があります。

  • のみBarImplBarインターフェイスを実装します。
  • BarImplは、DoStuffメソッドで例外をスローすることができます。

Bar.DoStuff xml docにこれらの例外を記録することは意味がありますか?事前に

おかげで、

答えて

3

はい - BarImplが唯一の実装者ではない場合でもそうです。

私が使用したいの例では、このクラスの実装抽象Readメソッドは、このメソッドを使用するときにStreamインスタンスのユーザーがスローされることを期待するかもしれない例外の全体の負荷を示していますStreamクラスで、順番にすべきさまざまなシナリオの下で投げます。

+0

+1 'Stream.Read'参照の+1!優れた例 – GETah

1

はいそれはありません。これは、他の開発者が準備ができて発生する可能性のある例外を処理するのに役立ちます。 MSDNのドキュメントを参照することで、何回も例外を準備するのに役立つと考えてください。

+0

クイック返信ありがとう – GETah

1

私は扱うことができる例外のみを文書化します。他の例外を記録するのは意味がありません。私の "ハンドリング"例外の定義は、メソッドが例外をキャッチすることによって約束された結果を提供できるということです。

だから、この答えはこれらの例外です:

あなたはオープン/クローズの原則をフォローしたい場合は、インターフェイスではなく具体的​​なクラスの例外をドキュメント化する必要があります。また、同じシナリオが発生した場合、すべての実装で同じ例外がスローされなければなりません。

+0

オープン/クローズの原則+1 +1 – GETah

関連する問題