RuntimeExceptionをスローするメソッドは、メソッドシグネチャでそれを示す必要がありますか？

たとえば、frameworks / JDKの多くのメソッドがスローする可能性があります

java.lang.SecurityException 

ただし、これはメソッドシグネチャには示されていません（これは通常、チェックされた例外のために予約されているためです）。メソッドsigsでRuntimeExceptionsを宣言することには、多くの利点があることを主張したいと思います（たとえば、静的型チェックに似ています）。私は酔っていますか、それともそうではありませんか？

そのAPIのユーザーに誤解を与えるため、署名で未チェックの例外を宣言しません。例外を明示的に処理する必要があるかどうかは、もはや明らかではありません。

javadocで宣言することは、誰かが必要だと思った場合に処理できるため、より良いアプローチですが、必要に応じて無視できることを知っています。これにより、チェックされているものとチェックされていないものの区別が明確になります。

以下からのOracleのJavaチュートリアル：

「スローできる例外を含め、メソッドのAPIを文書化するのが非常に良い場合は、ランタイム例外も指定してみませんか？」ランタイム例外は、プログラミングの問題の結果である問題を表します。そのため、APIクライアントコードは、それらから回復したり、何らかの方法でそれらを処理したりすることを合理的に期待することはできません。このような問題には、ゼロ除算などの算術例外が含まれます。null参照を介してオブジェクトにアクセスしようとするなどのポインタ例外。インデックスが大きすぎたり小さすぎたりすることで配列要素にアクセスしようとするなど、インデックスの例外。

ランタイム例外はプログラムのどこでも発生する可能性があり、通常の例外では非常に多くなる可能性があります。すべてのメソッド宣言にランタイム例外を追加する必要があると、プログラムの明確さが低下します。

Collection＃addのjavadocを見てください

言及されているチェックされていない例外がたくさんあります：

Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.

忍耐力がある場合は、この方法でメソッドによってスローされる可能性のある例外を完全に文書化することをお勧めします。ある意味で、チェックされた例外はある程度自己文書化されるため、チェックされていない例外に対してこれを行うことはさらに重要です（コンパイラーは呼び出し元のコードにそれらを確認させます）。

私の見解では、少なくともメソッドのjavadocでランタイム例外を宣言することをお勧めします。署名でそれを宣言すると、何か問題が発生したときに何が起こるかがさらに明確になります。これが、この情報を提供することを提案する私の主な理由です。

参考：時間が経つにつれて（現在は2017年）、javadocのみでそれらを文書化し、チェックされた例外を可能な限り回避することに今ははるかに傾いています。

私の見解では、チェックされていない例外は、その性質に反するため、メソッドシグネチャで宣言しないでください。

ただし、メソッドが未チェックの例外をスローする可能性がある場合は、Javadocの@throwsで発生する可能性のある状況に注意して、メソッドを呼び出す他の人が何がうまくいかないかを理解するのに役立ちます。ただし、これは、呼び出し元が処理できる可能性が高い例外（入力不良によるNPEなど）の場合にのみ役立ちます。

他の人が使用するためにAPIを作成している場合、APIで意図を明示的に文書化する十分な理由があり、メソッドシグネチャでRuntimeExceptionsを宣言することにマイナス面はありません。

これは、チェックされた例外に関する議論と関係があります。ほとんどの人は、メソッドのシグネチャで例外を宣言すべきではないことに同意します。

ランタイム例外の使用方法に関する議論もあります。ランタイム例外はプログラミングエラーまたは致命的な状態を示すべきであるというあるポスターに同意します。したがって、署名でそれらを宣言するメリットはあまりありません。すべてのメソッドは、潜在的に1つを介して可能性があります。