例如，框架/ JDK中的许多方法都可能抛出
java.lang.SecurityException
但是方法签名中没有指出（因为这是通常为已检查的例外保留的做法）。 我想说，在方法sigs中声明RuntimeExceptions有许多好处（例如类似于静态类型检查）。我喝醉了还是其他？
答案 0 :(得分：59)
我不会在签名中声明未经检查的异常，因为它会误导该API的用户。是否必须明确处理异常已经不再明显了。
在javadoc中声明它是一种更好的方法，因为它允许某人在认为有必要时处理它，但知道如果他们想要可以忽略它。这使得已选中和未选中之间的分离清晰。
答案 1 :(得分：29)
“如果记录方法的API非常好，包括异常 它可以抛出，为什么不指定运行时异常？“运行时 异常表示编程导致的问题 问题，因此，API客户端代码不能合理地 期望从他们身上恢复或以任何方式处理他们。这样 问题包括算术异常，例如除以零; 指针异常，例如尝试通过null访问对象 参考;和索引异常，例如尝试访问 数组元素通过索引太大或太小。
运行时异常可以发生在程序的任何地方，也可以是典型的 一个他们可以很多。 必须添加运行时异常 每个方法声明都会降低程序的清晰度。
答案 2 :(得分：16)
查看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.
如果您有耐心，我建议您以这种方式彻底记录您的方法引发的可能异常。在某种程度上，对未经检查的异常执行此操作更为重要，因为已检查的异常在某种程度上是自我记录的（编译器会强制调用代码来确认它们）。
答案 3 :(得分：6)
在我看来，最好至少在方法的javadoc中声明运行时异常。在签名中声明它会使出现问题时可能发生的事情变得更加明显。这是我建议提供此信息的主要原因。
仅供参考：随着时间的推移（现在是2017年），我现在更倾向于仅在javadoc中记录它们并尽可能避免检查异常。
答案 4 :(得分：3)
在我看来，不应该在方法签名中声明未经检查的异常，因为这与其性质相反。
但是，如果某个方法可能抛出一些未经检查的异常，则注意到Javadoc中@throws的可能情况可能有助于其他人调用该方法来理解可能出错的地方。这仅适用于调用者可能能够处理的异常（例如由于输入错误等导致的NPE）。
答案 5 :(得分：3)
如果您正在编写api供其他人使用，那么有足够的理由在api中明确记录您的意图，并且在方法签名中声明RuntimeExceptions没有任何缺点。
答案 6 :(得分：1)
这与关于checked exceptions的讨论有关。大多数人都同意不应在方法签名中声明异常。
还有一个关于如何使用运行时异常的discussion。我同意一张海报，运行时异常应表示编程错误或致命条件。因此在签名中声明它们没有多少价值。每种方法都可能通过一种方法。