2017-11-27 16 views
1

Kotlinはチェック例外を取得していないので、インターフェイスメソッドによってスローされると予想される例外を文書化する正しい方法は何ですか?私はそれをインターフェイスまたは実装クラスに記述するべきですか(具体的なメソッドが実際にそれをスローする場合のみ)?Kotlin - インターフェイスメソッドによってスローされたドキュメント例外

+0

'@ Throws'アノテーションを使用できます。 IMOはこれをインターフェイスメソッドに配置するのが最も理にかなっています。 –

+0

実装上にある場合、インタフェースを受け取る関数は、それが投げることができるか、投げることができるかを知りません。さらに悪いことに、異なるものを投げている2つの実装があります。参照:[LSP](https://en.wikipedia.org/wiki/Liskov_substitution_principle) – chris

答えて

0

クライアントはインターフェイスに対してプログラムを作成するので、そのインターフェイスのJavadoc/KDocでドキュメントを作成することをお勧めします。

Oracleをお勧めします:それは投げることができる例外を含む、メソッドのAPIを文書化するので、良いことだ場合

は、なぜランタイムを指定しないで、あなたは実際にそれらは例えばthisスレッドで議論されている文書化すべきかどうか例外も?
実行時例外は、プログラミング上の問題の結果発生する問題を表しているため、APIクライアントコードは、APIクライアントコードから回復したり、何らかの形で処理することは合理的に期待できません。このような問題には、ゼロ除算などの算術例外が含まれます。 null参照によってオブジェクトにアクセスしようとするなどのポインタ例外。大きすぎるまたは小さすぎるインデックスを使用して配列要素にアクセスしようとするなど、例外のインデックス付けを行うことができます。
実行時例外はプログラム内のどこでも発生する可能性があり、典型的な例外では非常に多くなる可能性があります。すべてのメソッド宣言でランタイム例外を追加すると、プログラムの明瞭度が低下します。

情報がクライアントに役立つ場合は、文書化する必要があります(つまり、クライアントが対応できる場合、たとえばIOException)。 IllegalArgumentExceptionなどの「通常の」実行時例外については、「いいえ」と言いますが、それらを文書化しないでください。

関連する問題