私はHTMLヘルプファイルを生成できるように私のコメントにC＃コードをデコレートしています。インターフェイスとその実装のドキュメント化
私はしばしばインターフェイスを宣言し、文書化します。しかし、それらのインタフェースを実装しているクラスは、実装に応じて特定の例外を投げることができます。
クライアントは、使用しているインターフェイスのみを認識していることがあります。実装者によってスローされる可能性のある例外を追加して、インタフェースを文書化する必要がありますか？
インターフェイスの実装者がフレームワークの代わりにこれらをスローするようにカスタム例外を作成する必要がありますか？
これは明らかです。
おかげ
EDIT 1月4日2010：私は、私は完全にあなたの質問を理解して確認していない（と私はhttp://blog.mikecouturier.com/2010/01/creating-custom-exceptions-in-net-right.html
でこれと.NETのカスタム例外に関するブログ記事を書くことにしましたJava、C＃の開発者ではない）が、本質的にポリモーフィズムの問題について尋ねているようです：もし誰かがXとYを投げるために宣言されたインタフェース上のメソッドを使用すると、実装がZをスローするとどうなりますか？
従うべきことの1つは、基本的に、サブタイプがスーパータイプの動作に準拠する必要があるということです。つまり、インターフェースのメソッドが1つのタイプの例外（たとえばヌルポインター例外）だけをスローできることを文書化している場合、呼び出し元との契約では、これが唯一のものであるということです。あなたが何かを投げると、あなたはそれらを驚かせることができます。
スーパータイプの特定のサブタイプに関する事柄を文書化することは、不要な結合を作成するので適切ではありません。私は、実装が宣言とは異なる振る舞いをするかもしれないという事実が、宣言が十分に洗練されていないことを示唆している可能性があることをより懸念しています。
あなたのメソッドが投げる可能性があるすべてのタイプの例外が何であるか考えてみてください。それらのスーパータイプを作成し、インタフェースメソッドで明示的に宣言します（たとえば、このメソッドはいくつかの「計算例外」を投げることができます）。その後、実装では、より詳細な計算例外を投げたり、実装固有の計算例外のサブタイプを投げたりしても、それにも適合します。
に答えることができます。ちょうど私が言うつもりだった。 –
あなたはそれを釘付けにしました。サブタイプがそれらをスローするようにカスタム例外を作成します。サブタイプがXMLまたはJSON（実装に応じて）で応答を読み取ることができない場合、（たとえば、XmlExceptionではなく）ParseExceptionをスローすることができるように、一般的な処理を行います。ありがとう！ –
私はUriが言っていることすべてに同意します。必要に応じて拡張できるカスタム例外を作成すると、インターフェイスに入力されたパラメータを使用するメソッドがその例外をキャッチでき、サブタイプされた例外もキャッチされます。あなたはコメントの発言部分を使用することができます実装のための文書化の面では
は（」あなたを想定していることを、あなたのエラー条件の使用について説明し、既存の.NET Frameworkの例外があるかどう
は、不しかし、それらを作成しないでくださいXMLコメントを使用して）実装者が何かを行うことを期待する方法を記述します。明らかにこれは強制的なものではありませんが、開発者があなたのAPIを使用する際に役立つガイドラインとして役立ちます。
はい私は、実装者が備考欄で探すべきすべてをカバーしようとしています！また、既存の例外を可能な限り使用しようとしています。あなたの助けをありがとう –
詳細の追加のための+1 –
私はロブに同意します。私の経験では、あまりにも多くの例外サブタイプは実際にはあまり追加していないと言います。ほとんどの人は、より意味のある状態データで初期化された例外オブジェクト、さらに良いエラーメッセージを好むでしょう。私は誰かが特定のエラーから回復することを私が明確にしたいと思えば、タイプされた例外を使います。 – Uri
あなた自身の質問 – Jodrell