Сообщение об ошибке проверки Null, поскольку оно равно null или было null

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

То есть вместо "username is null" скажите "username should not be null".

Об использовании библиотек для проверки предварительных условий

В качестве подсказки вы можете использовать одну из множества библиотек, предназначенных для облегчения проверки предварительных условий. Многие коды в Guava используют com.google.common.base.Preconditions

Простые статические методы, которые будут вызываться в начале ваших собственных методов для проверки правильности аргументов и состояния. Это позволяет создавать такие конструкции, как

 if (count <= 0) {
   throw new IllegalArgumentException("must be positive: " + count);
 }

заменить на более компактный

 checkArgument(count > 0, "must be positive: %s", count);

Более важным здесь является то, что он имеет checkNotNull, что позволяет просто написать:

  checkNotNull(username, "username should not be null");

Обратите внимание, как естественно выглядит приведенный выше код с подробным сообщением, в котором явно указывается требование, которое было нарушено.

Альтернатива констатации фактов более неудобна:

 // Awkward!
 checkArgument(count > 0, "is negative or zero: %s", count);
 checkNotNull(username, "username is null");

Более того, это также потенциально менее полезно, поскольку клиент может уже знать об этом факте, а исключение не поможет ему понять, каковы фактические требования.

On IllegalArgumentException vs NullPointerException

В то время как ваш исходный код выдает IllegalArgumentException для null аргументов, вместо этого Preconditions.checkNotNull в Guava выдает NullPointerException.

Это соответствует правилам, установленным API:

NullPointerException: приложения должны генерировать экземпляры этого класс для указания других незаконных видов использования объекта null.

Кроме того, вот цитата из Effective Java 2nd Edition: пункт 60. Отдавайте предпочтение использованию стандартных исключений:

Возможно, все ошибочные вызовы методов сводятся к недопустимому аргументу или недопустимому состоянию, но другие исключения стандартно используются для определенных видов недопустимых аргументов и состояний. Если вызывающий объект передает null в каком-либо параметре, для которого запрещены нулевые значения, соглашение требует, чтобы выбрасывалось NullPointerException, а не IllegalArgumentException.

равно нулю, так как аргумент по-прежнему равен нулю..

Однако почему бы просто не сгенерировать исключение NullPointerException без сообщения?

я бы предложил сказать

  if (userName == null) {
     throw new IllegalArgumentException("username == null");
   }

поскольку это настолько фатально, что программист все равно должен на это посмотреть. Ссылка на оскорбительный фрагмент кода в сообщении об исключении — это самое простое, что я могу себе представить.

Я был бы склонен написать это:

public User getUser(String username) {
   if (username.length() == 0) {
       throw new IllegalArgumentException("username is empty");   
   }
   // ...
}

Это убивает двух зайцев одним выстрелом. Во-первых, он обнаруживает случай, когда имя пользователя представляет собой пустую строку, что (ради аргумента) я предполагаю как ошибку. Во-вторых, если параметр равен null, попытка отправки вызова length даст NullPointerException.

Для справки: ожидаемое исключение, вызываемое для неожиданного null, равно NullPointerException. Если ваша основная причина не использовать его заключается в том, что NPE обычно не имеют сообщения, закодируйте его следующим образом:

public User getUser(String username){
   if (username == null){
       throw new NullPointerException("username is null");   
   }
   if (username.length() == 0) {
       throw new IllegalArgumentException("username is empty");   
   }
   // ...
}

Зачем использовать NPE здесь? Поскольку NPE почти всегда указывает на другую проблему, чем на другие типы ошибок проверки аргументов; например поле или ячейка массива, которые не были инициализированы, или «необязательное» значение, которое не обрабатывается должным образом.

Наконец к вопросу:

Что лучше: "is null" или "was null" и почему?

Это вопрос мнения, но я бы написал "is null".

• Потому что сообщение сообщает о состоянии, когда было выдано исключение.
• Потому что так принято делать.