HTML ヘルプ ファイルを作成できるように、C# コードをコメントで装飾しています。
私はよくインターフェイスを宣言して文書化します。ただし、これらのインターフェイスを実装するクラスは、実装に応じて特定の例外をスローできます。
場合によっては、クライアントは自分が使用しているインターフェイスしか認識していないことがあります。実装者によってスローされる可能性のある例外を追加して、インターフェイスを文書化する必要がありますか?
インターフェイスの実装者がフレームワークのものではなくこれらをスローするように、カスタム例外を作成/文書化する必要がありますか?
これが明確であることを願っています！
ありがとう
編集 2010 年 1 月 4 日: http://blog.mikecouturier.com/2010/01/creating-custom-exceptions-in-net-right.htmlで、これと .NET のカスタム例外に関するブログ投稿を書くことにしました。
私はあなたの質問を完全に理解しているとは確信していません (そして私は Java であり、C# 開発者ではありません)。 X と Y、実装が Z をスローするとどうなりますか?
従うべきことの 1 つは、基本的にサブタイプがスーパータイプの動作に準拠する必要があることを示す準拠の原則です。つまり、インターフェイス内のメソッドが 1 つのタイプの例外 (null ポインター例外など) のみをスローできることを文書化する場合、呼び出し元との契約は、これだけを監視する必要があるということです。何か他のものを投げると、彼らを驚かせることができます.
スーパータイプの特定のサブタイプに関することを文書化することは、不必要な結合を作成するため、良い考えではありません。宣言が十分に肉付けされていないことを示唆している可能性があるため、実装が宣言とは異なる動作をする可能性があるという事実についてもっと心配します。
メソッドがスローする可能性のあるすべての例外の種類を考えてみてください。それらのスーパータイプを作成し、インターフェイス メソッドで明示的に宣言します (たとえば、このメソッドは「計算例外」をスローできます)。次に、実装で、より詳細な計算例外をスローするか、実装に固有の計算例外のサブタイプをスローしても、準拠します。
私はUriが言うすべてに同意します-必要に応じて拡張できるカスタム例外を適切に作成する必要があります。その後、インターフェイスに型指定されたパラメーターを使用するメソッドがその例外をキャッチでき、サブタイプの例外もキャッチします。
ただし、エラー状態を説明する既存の .Net Framework 例外がある場合は、それらを不必要に作成しないでください。
実装者向けの文書化に関しては、コメントのコメント セクションを使用して (XML コメントを使用していると仮定して)、実装者がどのように行動することを期待するかなどを記述することができます。明らかに、これは強制力のあるものではありませんが、開発者が API を使用する際に役立つガイドラインとして役立ちます。