Objects.requireNonNull(T obj) вместо нулевых проверок и вручную выбрасывает IllegalArgumentException?
Всякий раз, когда мне приходилось проверять, не заданы ли заданные параметры методу null, я использовал для записи нулевую проверку и выбрал IllegalArgumentException, если ошибка null проверена:
if (user == null) {
throw new IllegalArgumentException("User can't be null.");
}
Однако, прочитав исходный код некоторых классов Java 8, таких как ArrayList, я узнал, что Oracle использует Objects.requireNonNull, чтобы проверить параметр на нулевое значение, а затем, если тест завершился неудачей, выдается NullPointerException.
Таким образом, предыдущий фрагмент кода должен выглядеть следующим образом:
Objects.requireNonNull(user, "User can't be null.");
Меньше и читабельнее.
Предполагая, что я контролирую всю обработку исключений системы (даже если я не должен, иногда это часть бизнеса для обработки этих непроверенных исключений), следует заменить мой IllegalArgumentExceptions на NullPointerException и использовать Objects.requireNonNull вместо того, чтобы писать свою собственную проверку нуля и исключение исключения?
Ответы
Ответ 1
Использование Objects.requireNonNull(c) - очень элегантный способ проверить, является ли элемент не нулевым. Но есть интересная дискуссия о выборе NullPointerException или IllegalArgumentException → IllegalArgumentException или NullPointerException для нулевого параметра?. Таким образом, бросание NullPointerException - это способ java, чтобы выразить, что ссылка имеет значение null.
В противном случае вы можете создать свой собственный метод requireNotNull(). Это просто:
public static <T> T requireNonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
и вы можете изменить исключение NullPointerException на IllegalArgumentException.
Ответ 2
Обсуждается вопрос о том, какое исключение следует вызывать, когда метод получает нулевое значение, которого он не ожидает. Некоторые люди утверждают, что для NullPointerException, некоторые люди утверждают, что для IllegalArgumentException. Кажется, что путь JDK заключается в том, чтобы бросать NullPointerException в таких случаях, поэтому Objects.requireNonNull выдает его.
Но я бы не стал модифицировать существующий код только из-за этого метода, хотя вам может потребоваться использовать Objects.requireNonNull в новом коде. (Использование его в общем делает код более читаемым, чем проверка на нуль и выдача исключения вручную.)
