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