在isValid(int)from java.sql.Connection（接口）的文档中：
http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#isValid(int)
它声明它将抛出一个“SQLException如果提供的值timeout小于 0”。
实现者是否应该将其解读为“SQLException 当且仅当所提供的值timeout小于 0”，或者他们是否也可以出于一系列其他原因随意扔掉它？
编辑：我想我很困惑/恼火他们为什么不使用IllegalArgumentException. 我希望SQLException指的是“数据库似乎已经融化”之类的东西，而不是“你对这个论点有一个基本的误解”。
我不会将其解读为“当且仅当”（尽管可能是这样）。如果timeout小于0，肯定会抛出异常，但这并不一定意味着在其他情况下不会抛出。我认为开发人员打算将其解读为“当且仅当”，但我只是在推测，因此您无法确定。
该方法检查超时是否小于 0；如果是，它会抛出异常。但是，在算法执行期间仍然可以随意抛出意外异常。
如果您要覆盖它，那么您应该 pbehave 作为您的超类，只是使用不同的实现。由于多态性，您的子类可以被实例化，但作为超类引用。因此，如果您出于超类未记录的原因引发异常，那么您只会造成混乱和潜在的错误代码。
我认为假设“如果为 timeout 提供的值小于 0”是唯一Connection isValid会抛出 的情况是相当安全的SQLException，但我认为对于文档中的每个类和每个方法一般来说假设是不安全的throws 条件是唯一会导致抛出异常的条件。
我会将其解释为您以前的解释（“当且仅当”）。我会想象出于任何其他原因的 SQLException 对调用者没有用处。如果 isValid 调用因任何其他原因失败，则返回“false”响应似乎是最合适的。
我完全理解您对 JDBC 的不满。看起来 JDBC 团队并不认为他们需要遵守通过 Java SE 平台的其余部分建立的约定。
这在过去给我造成了很大的困惑，例如，正如您所指出的，他们的异常处理并不像它可能的那样标准。我还希望 SQLException 是一个运行时异常（或者至少必须与数据库相关的异常层次结构，一个选中一个未选中）。最后，我最大的烦恼是 JDBC 中的索引是 1 索引的，而在 Java 的其余部分通常是 0 索引。
在这种情况下，我认为您假设“当且仅当”可能是正确的。也就是说，您是否正在尝试实现自己的驱动程序？如果是这样，您还期待什么其他异常情况？
是的，当且仅当超时值小于 0 时，它才应该抛出异常。
如果连接有问题，则该方法应返回false。
作为一个整体，我读到 javadoc 说如果连接无效（意味着没有关闭且不可用），或者如果超过超时，它将返回 false。
但是，如果对数据库的连接有效性查询出现其他问题，则仍可能引发 SQLException。（例如，查询是针对缺少的数据库的所需系统表，或者事务在检查过程中回滚）。
如果超时值小于零，将始终抛出 SQLException。
话虽如此，（通常是JDBC，尤其是）这个规范存在很多问题。
什么定义了无效连接？如果试图找出一个数据库错误，我们真的可以说我们不知道连接是否有效。反正它很可能坏了。我唯一能想到的是连接仍然需要关闭，而 valid == false 可能意味着连接已死，无需关闭它。这导致了下一个问题：
Valid 没有正式定义。这意味着没有关闭和其他东西。但是其他的东西有点模糊。应该是可以用的意思，但是如果没有关闭，但是不可用怎么办？
最后，为什么对负数如此不宽容？说起来也很简单：值为 0 或更小表示超时未应用于数据库操作。
当然，isClosed()的规范没有更新以识别新的 isValid(int) 方法。
一般来说，JDBC API 确实是一种讽刺。
另一方面，如果含义是当且仅当，它应该这么说，并且如果由于任何其他原因不能抛出 SQLException，那么这应该是一个运行时异常（例如 IllegalArgumentException），因为传递一个负值只会是一个编程错误。另一方面，如果可以出于其他原因抛出 SQLException，那么至少可以说，当必须处理已检查的异常时，引入单独的异常是不值得的。我不确定我是否同意这个论点，但至少它可能有优点。（注意，我写最后一段并不是为了证明规范并不意味着当且仅当，而是作为进一步的批评，如果这就是它的意思。）