Как вы интерпретируете этот кусочек Javadoc?

Question

В документации на isValid(int) от java.sql.Connection (интерфейс):

http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#isValid(int)

заявляет, что выдаст «SQLException, если значение, предоставленное для timeout меньше 0».

Должны ли разработчики читать это как "SQLException в том и только в том случае, если значение, указанное для timeout меньше 0", или они тоже могут его выбросить по множеству других причин? 1016 *

РЕДАКТИРОВАТЬ: Я думаю, я смущен / раздражен, почему они не использовали IllegalArgumentException. Я ожидаю, что SQLException будет означать что-то вроде «база данных, похоже, растаяла», а не «у вас есть базовое неправильное понимание того, что это за аргумент».

Answer 1

Я бы не стал читать это как «если и только если» (хотя, вероятно, это так). Если timeout меньше 0, исключение обязательно будет выдано, но это не обязательно означает, что оно не будет выдано в других случаях. Я думаю, что разработчики намеревались это читать как "если и только если", но я просто размышляю, так что вы не можете быть в этом уверены.

Answer 2

Этот метод проверяет, является ли время ожидания меньше 0; если это так, он выдает исключение. Тем не менее, все еще можно генерировать непреднамеренное исключение во время выполнения алгоритма.

Если вы переопределяете его, тогда вы должны иметь pbehave как ваш суперкласс, просто с другой реализацией. Из-за олиморфизма ваш подкласс может быть создан, но на него ссылаются как на суперкласс. Поэтому, если вы выдаете исключение по причине, что суперкласс не документирует, то вы можете только создать путаницу и потенциально ошибочный код.

Answer 3

Я думаю, что довольно безопасно предположить, что «если значение, указанное для тайм-аута меньше 0», это единственный случай, когда Connection isValid выдаст SQLException, но я не думаю, что это безопаснодля каждого класса и для каждого метода в целом предполагается, что задокументированное условие throw является единственным условием, которое вызывает исключение.

Answer 4

В целом, я прочитал javadoc, чтобы сказать, что если соединение недопустимо (имеется в виду, что оно не закрыто и не может быть использовано), или если превышено время ожидания, оно вернет false.

Если, однако, что-то не так с запросом к базе данных о достоверности соединения, SQLException все еще может быть сгенерировано. (Скажем, например, запрос относится к требуемой системной таблице базы данных, которая отсутствует или транзакция откатывается в середине проверки).

SQLException всегда генерируется, если значение тайм-аута меньше нуля.

При этом существует множество проблем с (JDBC в целом и) этой спецификацией в частности.

Что определяет недопустимое соединение? Если выдается ошибка в базе данных, пытаясь выяснить, можем ли мы действительно сказать, что не знаем, допустимо ли соединение. Это, вероятно, сломано в любом случае. Единственное, о чем я могу думать, это то, что соединение все еще должно быть закрыто, тогда как valid == false может означать, что соединение не работает, нет необходимости закрывать его. Это приводит к следующей проблеме:

Действительный, формально не определен. Значит не закрыто и что-то еще. Но это что-то еще немного расплывчато. Это должно означать «можно использовать», но что, если оно не закрыто, но не может использоваться?

И, наконец, почему так нетерпимо относиться к отрицательному числу? Это так же легко сказать: значение 0 или меньше указывает, что тайм-аут не применяется к операции базы данных.

И, конечно, спецификация isClosed () не была обновлена ​​для распознавания нового метода isValid (int).

API JDBC действительно пародия в целом.

С другой стороны, если значение равно тогда и только тогда, когда , это должно было бы сказать это, и если SQLException не может быть сгенерировано по любой другой причине, то это должно быть исключение времени выполнения (например, IllegalArgumentException ), потому что передача отрицательного значения будет просто ошибкой программирования. Если, с другой стороны, SQLException может быть вызвано по другим причинам, то, по крайней мере, можно утверждать, что не стоило вводить отдельное исключение, когда проверенное исключение все равно нужно было обработать. Я не уверен, что согласен с аргументом, но, по крайней мере, он может быть достоин. (Обратите внимание, я не пишу этот последний абзац как доказательство того, что спецификация не имеет в виду, если и только если, а скорее как дополнительную критику, если это то, что она означает.)

Answer 5

Да, должно выдаваться исключение тогда и только тогда, когда значение времени ожидания меньше 0.

Если есть проблема с подключением, метод должен вернуть false .

Answer 6

Я полностью понимаю ваше разочарование в связи с JDBC. Кажется, что команда JDBC не думала, что им нужно соответствовать соглашениям, установленным на остальной части платформы Java SE.

Это вызывало у меня большую путаницу в прошлом, например, их обработка исключений не так стандартна, как могла бы быть, как вы указали. Я также хотел бы, чтобы SQLException были исключением времени выполнения (или, по крайней мере, имели бы отношение к иерархиям исключений, связанных с базой данных, одна проверенная и одна не проверенная). И, наконец, моя самая большая любимая особенность в том, что индексы в JDBC индексируются 1, тогда как в остальной части Java, как правило, индексируются 0.

В этом случае, я думаю, вы, вероятно, правы, предполагая, «если и только если». Тем не менее, вы пытаетесь реализовать свой собственный драйвер? Если да, то какое еще исключение вы ожидаете?

Answer 7

я бы интерпретировал это как ваше прежнее толкование («тогда и только тогда»). я бы предположил, что SQLException по любой другой причине не будет полезным для вызывающей стороны. если вызов isValid завершится неудачей по любой другой причине, ответ «ложь» будет наиболее подходящим.