Понимать аннотации @Nonnull и @CheckForNull

В моем проекте Spring есть сервис

  public Pageable<MyObject>findAccount(String accountExternalId){
  if (accountExternalId== null) {
            throw new ProjectException("Missing account");
     }
  ...
}

Поэтому, когда я использую java 5 аргументов, мне нужно сделать 5 ifs, чтобы проверить наличие нулевых входных объектов. Не делать этого я хочу использовать javax.annotation.Nonnull а также javax.annotation.CheckForNull и делать что-то подобное.

public Pageable<MyObject>findAccount(@Nonnull String accountExternalId){
         ...
  }

и использовать findbugs

  <groupId>
        com.google.code.findbugs
  </groupId>
  <artifactId>
        findbugs
  </artifactId>

Поэтому мне интересно, как эта аннотация мешает пользователям не передавать значения Null? Или это только примечание, что вы не должны принимать значение NULL и только для информационных целей?

2 ответа

Поэтому мне интересно, как эта аннотация мешает пользователям не передавать значения Null? Или это только примечание, что вы не должны принимать значение NULL и только для информационных целей?

Второй.

Однако FindBugs также использует некоторые из этих аннотаций для своего анализа; например, если у вас есть @Nullable Параметр (или возвращаемое значение метода) и FindBugs обнаруживает в коде, что вы не проверяете, что параметр (или возвращаемое значение метода) является нулевым, прежде чем использовать его, это вызовет проблему.

Если @Nonnull тогда это в основном говорит, что вызывающая сторона должна гарантировать, что ненулевые параметры передаются методу или метод не возвращает нуль.

(не уверен насчет разницы между @CheckForNull а также @Nullable хоть)

У вас есть два варианта:

  • разрешить клиентскому коду передавать нулевые значения, но при этом выдает ошибку времени выполнения.
  • запретить клиентскому коду передавать нулевые значения, никогда не запуская код, который может это сделать.

Подход проверки во время выполнения используется вашим примером кода. Вы также можете генерировать проверки во время выполнения из @Nonnull аннотации.

Подход с проверкой во время компиляции (также известный как "статический анализ") является предпочтительным и представляет собой подход FindBugs. Автор библиотеки пишет контракт библиотеки, используя @Nonnull аннотаций; статический анализ выполняется при построении любого библиотечного кода; и если статический анализ показывает, что код клиента может нарушать контракт библиотеки, код клиента не должен выполняться.

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

Если вам нужна гарантия, вы не можете использовать FindBugs. FindBugs - лучший инструмент, который находит некоторые ошибки, но не пытается найти все ошибки. Кроме того, FindBugs лечит @NonNull как то же самое, что и @Nullable применительно к формальному параметру (!).

Возможно, вы захотите рассмотреть альтернативные инструменты для статической проверки. Одним из примеров является http://checkerframework.org/. В отличие от FindBugs, он дает гарантию правильности и использует гораздо более точный анализ. Недостатком является то, что вы должны аннотировать свой код @Nullable аннотации, но вы уже, кажется, готовы сделать это.

Другие вопросы по тегам