インターフェイスとその実装のドキュメント化

Question

私はHTMLヘルプファイルを生成できるように私のコメントにC＃コードをデコレートしています。

私はしばしばインターフェイスを宣言し、文書化します。しかし、それらのインタフェースを実装しているクラスは、実装に応じて特定の例外を投げることができます。

クライアントは、使用しているインターフェイスのみを認識していることがあります。実装者によってスローされる可能性のある例外を追加して、インタフェースを文書化する必要がありますか？

インターフェイスの実装者がフレームワークの代わりにこれらをスローするようにカスタム例外を作成する必要がありますか？

これは明らかです。

おかげ

EDIT 1月4日2010：私は、私は完全にあなたの質問を理解して確認していない（と私はhttp://blog.mikecouturier.com/2010/01/creating-custom-exceptions-in-net-right.html

Answer 1

でこれと.NETのカスタム例外に関するブログ記事を書くことにしましたJava、C＃の開発者ではない）が、本質的にポリモーフィズムの問題について尋ねているようです：もし誰かがXとYを投げるために宣言されたインタフェース上のメソッドを使用すると、実装がZをスローするとどうなりますか？

従うべきことの1つは、基本的に、サブタイプがスーパータイプの動作に準拠する必要があるということです。つまり、インターフェースのメソッドが1つのタイプの例外（たとえばヌルポインター例外）だけをスローできることを文書化している場合、呼び出し元との契約では、これが唯一のものであるということです。あなたが何かを投げると、あなたはそれらを驚かせることができます。

スーパータイプの特定のサブタイプに関する事柄を文書化することは、不要な結合を作成するので適切ではありません。私は、実装が宣言とは異なる振る舞いをするかもしれないという事実が、宣言が十分に洗練されていないことを示唆している可能性があることをより懸念しています。

あなたのメソッドが投げる可能性があるすべてのタイプの例外が何であるか考えてみてください。それらのスーパータイプを作成し、インタフェースメソッドで明示的に宣言します（たとえば、このメソッドはいくつかの「計算例外」を投げることができます）。その後、実装では、より詳細な計算例外を投げたり、実装固有の計算例外のサブタイプを投げたりしても、それにも適合します。

Answer 2

私はUriが言っていることすべてに同意します。必要に応じて拡張できるカスタム例外を作成すると、インターフェイスに入力されたパラメータを使用するメソッドがその例外をキャッチでき、サブタイプされた例外もキャッチされます。あなたはコメントの発言部分を使用することができます実装のための文書化の面では

は（」あなたを想定していることを、あなたのエラー条件の使用について説明し、既存の.NET Frameworkの例外があるかどう

は、不しかし、それらを作成しないでくださいXMLコメントを使用して）実装者が何かを行うことを期待する方法を記述します。明らかにこれは強制的なものではありませんが、開発者があなたのAPIを使用する際に役立つガイドラインとして役立ちます。