Ява: это в порядке, чтобы установить Целое число = пустой указатель?
У меня есть функция, которая возвращает идентификационный номер, если аргумент существует в базе данных. В противном случае это возвращает пустой указатель. Это просит о пустом исключении указателя? Отрицательные идентификационные номера не разрешены, но я думал, что это будет более ясно иметь несуществующие аргументы, возвращая пустой указатель вместо кода ошибки как-1. Что Вы думаете?
private Integer tidOfTerm(String name) throws SQLException {
String sql = "SELECT tid FROM term_data WHERE name = ?";
PreparedStatement prep = conn.prepareStatement(sql);
prep.setString(1, name);
ResultSet result = prep.getResultSet();
if (result.next()) {
return result.getInt("tid");
}
return null; // TODO: is this begging for a null pointer exception?
}
14 ответов
Это совершенно законно. Если вы хотите избежать NPE, сделайте исключение. Но не возвращайте отрицательное число. Если звонящий не проверит возвращаемое значение, у вас всегда будет проблема. Но делать вычисления false (так как результат умножается, например, на -1) определенно сложнее отладить, чем неисчерпаемое исключение.
Возвращение NULL В случае поиска, который не дает результат, является нормальным методом представления несуществующего. Я бы выбрал это в этом случае. (Методы поиска для стандартных классов карты Java являются примером для использования null , если карта не содержит ключа.)
Как для возврата специального значения для идентификатора, я бы только предложил Для этого, если ваша система уже содержит специальные значения, ведущие специальные идентификаторы.
Еще одна часто слышана возможность выбрасывать исключение в этом случае. Однако не совсем использовать исключения, чтобы пройти государство, поэтому я бы не сделал этого.
Да, это должно вызывать NPE и Да, вы должны уловить это в методе вызова (или в другом подходящем месте). Наиболее вероятная причина, по которой ваш метод будет возвращать NULL, это когда нет записей и правильный способ обработки - бросить исключение. И идеальное исключение, чтобы сказать кому-то, что у вас нет того, что он попросил, это NPE.
Возврат кода ошибки (например, -1) не годится, потому что:
a) если вы хотите обработать много ошибок (например, не можете прочитать БД, можете прочитать БД, но объекта в БД нет, найден объект, но что-то повреждено и т.д.), то возврат кода ошибки не различает типы ошибок.
b) в будущем, если -1 станет юридическим термином id, то изменить его будет сложно (если нужно использовать -1, то (EDIT: в C) хотя бы #define ERRORCODE -1 и использовать ERRORCODE повсюду)
.Пожалуйста, не пишите код, возвращающий ноль. Это означает, что каждый вызов Вашего кода ДОЛЖЕН проверять на наличие нуля, чтобы быть надежным. Каждый раз. Всегда.
Рассмотрим возможность возврата списка, содержащего количество возвращаемых значений, которое может быть нулем.
Я согласен с плакатами. Целое является оберткой и как таковое должно использоваться для вычислений, преобразований и т.д. (что, я думаю, вы и собираетесь делать). Не возвращайте ноль, используйте отрицательное число... это немного более элегантно и позволяет больше контроля. ИМХО.
Интересная проблема и большое количество возможных решений:
- Создайте метод Hasargument и требуют, чтобы пользователи могли его вызвать, проблема это может быть медленной и дублированной работой
- Исключение, если значение не находится в базе данных, следует использовать только в том случае, если это неожиданно
- , используйте дополнительные значения, чтобы указать недопустимое возвращение, нулевые и отрицательные значения будут работать для вас, но если не проверено, они могут вызвать проблемы позже в код.
- Верните обертку с помощью метода ISVALID () и GetValue (), где getValue () бросает исключение, когда он недействителен. Это решит бы проблемы 1 и 3, но может быть немного слишком Mutch.
Может быть сложно в комбинации с автобоксингом. Если я это сделаю:
final int tid = tidForTerm("term");
А "термина" не существует, то получу NPE, так как Java пытается распаковать Целое (нулевое) в примитивное int.
Тем не менее, бывают случаи, когда действительно хорошо использовать ноль для Целого числа. В сущностях, имеющих необязательные значения int, например, население города. В этом случае ноль будет означать отсутствие информации.
Это может вызвать большие проблемы для новичков. Хорошие кодеры распознают, что если имя недействитена тогда NULL может быть возвращено. Сказав, что более стандартная вещь - бросить некоторые исключение .
Вызовите функцию SetTimer . Это позволяет указать функцию обратного вызова или отправить в Windows WM_TIMER сообщение.
-121--3071539-Возможно выполнение каждого из потоков Net:: HTTP.get. И просто дождитесь, когда все нити закончатся.
BTW printing urls будет печатать как ссылку, так и содержимое.
-121--2894393-Не используйте код ошибки! Какое значение имеет ошибка? никогда ли она не станет законной возвратной ценностью? Ничего не выиграл.
Значение NULL не является хорошим. В большинстве случаев код вызывающего абонента должен проверять результат, если он не равен NULL. И иногда выбор может возвращать значение null. Должно ли оно обрабатываться иначе, чем ни одна строка?
Вместо возвращаемого значения null следует создать исключение типа NoSuchElityException. Это неконтролируемое исключение, вызывающий абонент может обработать его или передать. И если вызывающий абонент хочет обработать, try catch не сложнее, чем если не null.
Надеюсь, это не настоящий метод для тебя. Вы не закрываете Statement или ResultSet в области действия метода.
Я думаю, что это законно, чтобы вернуть нулю в этом случае. Просто убедитесь, что намерение правильно документировано.
Возвращая отрицательное значение в этом случае было бы в порядке, но это не всестороннее решение. Что если отрицательные значения были допущены в БД?
Редактировать : я хочу добавить слово о связанных обсуждениях, на которые относится к возврату нулей или пустых списков (или массивов). Я в пользу возвращения пустых списков или массивов вместо NULL, но контекст отличается. При попытке получить список, он обычно является частью родительского объекта, и он на самом деле имеет смысл для родительского объекта иметь пустой список вместо нулевой ссылки. В этом случае NULL имеет значение (= не найден), и нет никаких причин, чтобы не возвращать его.
Нет, это не будет. Он только бросит NPE, если вы выполняете операции на нем потом, как если бы это примитив без него. Например. I ++ и так далее. Ваш пример действителен (ожидайте от того, что сам код JDBC протекает ресурсы). Если вам не нужна актуальная ID , то вы можете с другой стороны, также просто вернуть Boolean .
Я предлагаю вам рассмотреть возможность варианта.
Опциональный шаблон действует как обертка вокруг вашего возвращенного типа, и определяет два особых случая: опция. None () и опция .some (). Таким образом, вы всегда знаете ваш возвращенный тип (опцию) и можете проверить, есть ли у вас значение в возвращенном объекте опции, используя такие методы, как опция. Sissome () и опция.
Таким образом, вы можете гарантировать, что у вас нет никаких неконкуренных нулей.
Конечно, все это происходит по стоимости дополнительной сложности кода.
Для получения дополнительной информации о типе опции см. здесь (Scala Code, но и тот же основной)
Я бы сказал, что лучшее решение зависит от того, как назван ваш метод, и вы должны учитывать, как называются ваши методы, а также должны ли они возвращать null или вызывать исключение.
tidOfTerm подразумевает, что термин должен существовать, поэтому обнаружение того, что он не существует, должно вызывать исключение.
Если имя термина находится под контролем вашего собственного кода и его отсутствие указывает на ошибку в вашем коде или среде, вы можете создать исключение IllegalArgumentException.
Если аргумент имени термина не находится под вашим контролем и отсутствие допустимого термина является совершенно допустимой ситуацией,тогда я бы переименовал ваш метод во что-то вроде findTidForTermName , давая небольшой намек на то, что будет выполняться какой-то поиск, и что, следовательно, существует вероятность того, что поиск может ничего не найти.