Что делает ключевое слово Java assert и когда его следует использовать?

На каких реальных примерах можно понять ключевую роль утверждений?

Утверждения (посредством ключевого слова assert ) были добавлены в Java 1.4. Они используются для проверки правильности инварианта в коде. Они никогда не должны запускаться в рабочем коде и указывают на ошибку или неправильное использование пути кода. Их можно активировать во время выполнения с помощью -eaпараметра javaкоманды, но по умолчанию они не включены.

Пример:

public Foo acquireFoo(int id) {
  Foo result = null;
  if (id > 50) {
    result = fooService.read(id);
  } else {
    result = new Foo(id);
  }
  assert result != null;

  return result;
}

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

Java не является проверяемым языком, что означает: вы не можете рассчитать, что результат вашей работы будет идеальным. Основной причиной этого являются указатели: они могут указывать куда угодно или никуда, поэтому они не могут быть рассчитаны как имеющие именно это значение, по крайней мере, в пределах разумного диапазона кода. Учитывая эту проблему, невозможно доказать, что ваш код в целом верен. Но что вы можете сделать, это доказать, что вы, по крайней мере, обнаружите каждую ошибку, когда она случится.

Эта идея основана на парадигме Design-by-Contract (DbC): вы сначала определяете (с математической точностью), что должен делать ваш метод, а затем проверяете это, проверяя его во время фактического выполнения. Пример:

// Calculates the sum of a (int) + b (int) and returns the result (int).
int sum(int a, int b) {
  return a + b;
}

Хотя это совершенно очевидно, что работает нормально, большинство программистов не увидят скрытую ошибку внутри этой (подсказка: Ariane V разбился из-за аналогичной ошибки). Теперь DbC определяет, что вы всегда должны проверять ввод и вывод функции, чтобы убедиться, что она работает правильно. Java может сделать это с помощью утверждений:

// Calculates the sum of a (int) + b (int) and returns the result (int).
int sum(int a, int b) {
    assert (Integer.MAX_VALUE - a >= b) : "Value of " + a + " + " + b + " is too large to add.";
  final int result = a + b;
    assert (result - a == b) : "Sum of " + a + " + " + b + " returned wrong sum " + result;
  return result;
}

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

Исключения Java представляют собой похожую концепцию, но они не в состоянии проверить все. Если вы хотите еще больше проверок (за счет скорости выполнения), вам нужно использовать утверждения. Это приведет к раздуванию вашего кода, но в итоге вы сможете доставить продукт на удивительно короткое время разработки (чем раньше вы исправите ошибку, тем ниже будет стоимость). И дополнительно: если в вашем коде есть какая-либо ошибка, вы ее обнаружите. Нет способа проскочить ошибку и вызвать проблемы позже.

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

Утверждения - это инструмент фазы разработки для выявления ошибок в вашем коде. Они разработаны так, чтобы их можно было легко удалить, поэтому они не будут существовать в рабочем коде. Таким образом, утверждения не являются частью «решения», которое вы предоставляете клиенту. Это внутренние проверки, чтобы убедиться, что ваши предположения верны. Наиболее распространенным примером является проверка на ноль. Многие методы написаны так:

void doSomething(Widget widget) {
  if (widget != null) {
    widget.someMethod(); // ...
    ... // do more stuff with this widget
  }
}

Очень часто в таком методе виджет никогда не должен быть нулевым. Так что, если он нулевой, в вашем коде есть ошибка, которую нужно отследить. Но код выше никогда не скажет вам этого. Поэтому, стараясь написать «безопасный» код, вы также скрываете ошибку. Гораздо лучше написать такой код:

/**
 * @param Widget widget Should never be null
 */
void doSomething(Widget widget) {
  assert widget != null;
  widget.someMethod(); // ...
    ... // do more stuff with this widget
}

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

Теперь некоторые из ваших коллег будут возражать против этого кода, утверждая, что вы все равно должны поставить нулевую проверку, чтобы предотвратить исключение в работе. В этом случае утверждение все еще полезно. Вы можете написать это так:

void doSomething(Widget widget) {
  assert widget != null;
  if (widget != null) {
    widget.someMethod(); // ...
    ... // do more stuff with this widget
  }
}

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

Вот пример из реальной жизни: я однажды написал метод, который сравнивал два произвольных значения на равенство, где любое значение могло быть нулевым:

/**
 * Compare two values using equals(), after checking for null.
 * @param thisValue (may be null)
 * @param otherValue (may be null)
 * @return True if they are both null or if equals() returns true
 */
public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
  } else {
    result = thisValue.equals(otherValue);
  }
  return result;
}

Этот код делегирует работу equals()метода в случае, когда thisValue не является нулевым. Но предполагается, что equals()метод правильно выполняет контракт equals(), правильно обрабатывая нулевой параметр.

Коллега возразил против моего кода, сказав, что во многих наших классах есть ошибочные equals()методы, которые не проверяют на ноль, поэтому я должен поставить эту проверку в этот метод. Это спорно , если это имеет смысл, или если мы должны заставить эту ошибку, так что мы можем обнаружить его и исправить ее, но я отложила мой коллега и поставить в проверке нулевой, который я пометил с комментарием:

public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
  } else {
    result = otherValue != null && thisValue.equals(otherValue); // questionable null check
  }
  return result;
}

Дополнительная проверка здесь other != nullнеобходима только в том случае, если equals()метод не может проверить нулевое значение, как того требует его контракт.

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

public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
    assert otherValue == null || otherValue.equals(null) == false;
  } else {
    result = otherValue != null && thisValue.equals(otherValue);
    assert thisValue.equals(null) == false;
  }
  return result;
}

Важные моменты, которые следует иметь в виду:

1. Утверждения являются только инструментами фазы разработки.

2. Смысл утверждения в том, чтобы вы знали, есть ли ошибка не только в вашем коде, но и в вашей кодовой базе . (Утверждения здесь будут фактически отмечать ошибки в других классах.)

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

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

5. Утверждения не изменяют поведение кода в производственной среде, поэтому мой коллега рад, что проверка на ноль есть, и что этот метод будет выполняться правильно, даже если equals()метод содержит ошибки. Я счастлив, потому что я поймаю любой ошибочный equals()метод в разработке.

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

Много хороших ответов, объясняющих, что assertделает ключевое слово, но мало отвечающих на реальный вопрос, «когда assertключевое слово следует использовать в реальной жизни?»

Ответ: почти никогда .

Утверждения, как концепция, прекрасны. Хороший код имеет много if (...) throw ...утверждений (и их родственники любят Objects.requireNonNullи Math.addExact). Однако некоторые дизайнерские решения значительно ограничивают полезность самого assert ключевого слова .

Идея, стоящая за assertключевым словом, заключается в преждевременной оптимизации, и главной особенностью является возможность легко отключить все проверки. На самом деле, assertпроверки отключены по умолчанию.

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

Следовательно, использование if (...) throw ...должно быть предпочтительным, так же как это требуется для проверки значений параметров открытых методов и для бросания IllegalArgumentException.

Иногда может возникнуть соблазн написать инвариантную проверку, обработка которой занимает нежелательно много времени (и вызывается достаточно часто, чтобы это имело значение). Однако такие проверки замедляют тестирование, что также нежелательно. Такие трудоемкие проверки обычно записываются как модульные тесты. Тем не менее, иногда может иметь смысл использовать assertпо этой причине.

Не используйте assertпросто потому, что он чище и красивее чем if (...) throw ...(и я говорю это с большой болью, потому что мне нравится чистота и красота). Если вы просто не можете себе помочь и можете контролировать запуск своего приложения, тогда не стесняйтесь использовать, assertно всегда включайте утверждения в работе. Правда, это то, что я склонен делать. Я настаиваю на аннотации lombok, которая заставит assertдействовать больше как if (...) throw .... Проголосуйте за это здесь.

(Rant: разработчики JVM были группой ужасных, преждевременно оптимизирующих программистов. Вот почему вы слышали о столь многих проблемах безопасности в плагине Java и JVM. Они отказались включать базовые проверки и утверждения в производственный код, и мы продолжаем заплати цену.)

Вот наиболее распространенный вариант использования. Предположим, вы включаете значение enum:

switch (fruit) {
  case apple:
    // do something
    break;
  case pear:
    // do something
    break;
  case banana:
    // do something
    break;
}

Пока вы справляетесь с каждым делом, вы в порядке. Но когда-нибудь кто-нибудь добавит fig в ваше перечисление и забудет добавить его в ваш оператор switch. Это приводит к ошибке, которую сложно поймать, потому что эффекты не будут ощущаться до тех пор, пока вы не оставите оператор switch. Но если вы напишите свой переключатель, как это, вы можете сразу же поймать его:

switch (fruit) {
  case apple:
    // do something
    break;
  case pear:
    // do something
    break;
  case banana:
    // do something
    break;
  default:
    assert false : "Missing enum value: " + fruit;
}

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

Примером утверждения может быть проверка того, что определенная группа методов вызывается в правильном порядке (например, который hasNext()вызывается ранее next()в a Iterator).

Что делает ключевое слово assert в Java?

Давайте посмотрим на скомпилированный байт-код.

Мы сделаем вывод, что:

public class Assert {
    public static void main(String[] args) {
        assert System.currentTimeMillis() == 0L;
    }
}

генерирует почти тот же байт-код, что и:

public class Assert {
    static final boolean $assertionsDisabled =
        !Assert.class.desiredAssertionStatus();
    public static void main(String[] args) {
        if (!$assertionsDisabled) {
            if (System.currentTimeMillis() != 0L) {
                throw new AssertionError();
            }
        }
    }
}

где Assert.class.desiredAssertionStatus(), trueкогда -eaпередается в командной строке, и ложь в противном случае.

Мы используем, System.currentTimeMillis()чтобы убедиться, что он не будет оптимизирован ( assert true;сделал).

Синтетическое поле генерируется так, что Java нужно вызывать Assert.class.desiredAssertionStatus()только один раз во время загрузки, а затем кэшировать результат там. Смотрите также: Что означает «статический синтетический»?

Мы можем проверить это с помощью:

javac Assert.java
javap -c -constants -private -verbose Assert.class

В Oracle JDK 1.8.0_45 было сгенерировано синтетическое статическое поле (см. Также: Что означает «статический синтез»? ):

static final boolean $assertionsDisabled;
  descriptor: Z
  flags: ACC_STATIC, ACC_FINAL, ACC_SYNTHETIC

вместе со статическим инициализатором:

 0: ldc           #6                  // class Assert
 2: invokevirtual #7                  // Method java/lang Class.desiredAssertionStatus:()Z
 5: ifne          12
 8: iconst_1
 9: goto          13
12: iconst_0
13: putstatic     #2                  // Field $assertionsDisabled:Z
16: return

и основным методом является:

 0: getstatic     #2                  // Field $assertionsDisabled:Z
 3: ifne          22
 6: invokestatic  #3                  // Method java/lang/System.currentTimeMillis:()J
 9: lconst_0
10: lcmp
11: ifeq          22
14: new           #4                  // class java/lang/AssertionError
17: dup
18: invokespecial #5                  // Method java/lang/AssertionError."<init>":()V
21: athrow
22: return

Мы заключаем, что:

• поддержка уровня байт-кода отсутствует assert: это концепция языка Java
• assertможет быть достаточно хорошо эмулировано с системными свойствами -Pcom.me.assert=trueдля замены -eaв командной строке, и a throw new AssertionError().

Пример из реального мира из класса Stack (из утверждения в статьях Java )

public int pop() {
   // precondition
   assert !isEmpty() : "Stack is empty";
   return stack[--num];
}

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

Зачем утверждать что-то, когда вы знаете, что это правда? Это правда только тогда, когда все работает правильно. Если программа имеет дефект, это может быть на самом деле не так. Обнаружение этого ранее в процессе позволяет понять, что что-то не так.

assertЗаявление содержит это заявление вместе с дополнительным Stringсообщением.

Синтаксис для оператора assert имеет две формы:

assert boolean_expression;
assert boolean_expression: error_message;

Вот некоторые основные правила, которые определяют, где утверждения должны использоваться, а где они не должны использоваться. Утверждения должны использоваться для:

1. Проверка входных параметров частного метода. НЕ для публичных методов. publicметоды должны генерировать регулярные исключения при передаче неверных параметров.

2. В любом месте в программе, чтобы обеспечить достоверность факта, который почти наверняка верно.

Например, если вы уверены, что это будет только 1 или 2, вы можете использовать утверждение вроде этого:

...
if (i == 1)    {
    ...
}
else if (i == 2)    {
    ...
} else {
    assert false : "cannot happen. i is " + i;
}
...

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

Утверждения не должны использоваться для:

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

2. Проверка ограничений на то, что вводится пользователем. То же, что и выше.

3. Не следует использовать для побочных эффектов.

Например, это неправильное использование, потому что здесь утверждение используется для побочного эффекта вызова doSomething()метода.

public boolean doSomething() {
...    
}
public void someMethod() {       
assert doSomething(); 
}

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

boolean enabled = false;    
assert enabled = true;    
if (enabled) {
    System.out.println("Assertions are enabled");
} else {
    System.out.println("Assertions are disabled");
}

В дополнение ко всем отличным ответам, представленным здесь, официальное руководство по программированию на Java SE 7 содержит довольно краткое руководство по использованию assert; с несколькими точными примерами того, когда хорошая (и, что важно, плохая) идея использовать утверждения, и чем она отличается от создания исключений.

Ссылка на сайт

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

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

Я люблю это, но не знаю, как включить его в Eclipse / Android / ADT. Кажется, он выключен даже при отладке. (На этом есть поток, но он ссылается на «Java vm», который не отображается в конфигурации запуска ADT).

Вот утверждение, которое я написал на сервере для проекта Hibernate / SQL. Компонент-сущность имеет два фактически булевых свойства: isActive и isDefault. Каждый из них может иметь значение «Y» или «N» или ноль, что рассматривается как «N». Мы хотим убедиться, что клиент браузера ограничен этими тремя значениями. Итак, в мои сеттеры для этих двух свойств я добавил это утверждение:

assert new HashSet<String>(Arrays.asList("Y", "N", null)).contains(value) : value;

Обратите внимание на следующее.

1. Это утверждение только для этапа разработки. Если клиент отправляет неверное значение, мы поймем это рано и исправим это задолго до того, как достигнем производства. Утверждения относятся к дефектам, которые вы можете обнаружить рано.

2. Это утверждение медленное и неэффективное. Это нормально. Утверждения могут быть медленными. Нам все равно, потому что это инструменты только для разработки. Это не замедлит рабочий код, потому что утверждения будут отключены. (Есть некоторые разногласия по этому вопросу, к которым я вернусь позже.) Это приводит к моей следующей точке.

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

4. Это утверждение существует для проверки правильности работы клиента. Таким образом, к тому времени, когда мы достигнем производства, мы будем уверены, что клиент работает правильно, поэтому мы можем безопасно отключить утверждение.

5. Некоторые люди спрашивают это: если утверждение не нужно в производстве, почему бы просто не убрать их, когда вы закончите? Потому что они все еще понадобятся вам, когда вы начнете работать над следующей версией.

Некоторые люди утверждают, что вы никогда не должны использовать утверждения, потому что вы никогда не можете быть уверены, что все ошибки исчезли, поэтому вам нужно держать их рядом даже в производстве. И поэтому нет смысла использовать оператор assert, поскольку единственное преимущество утверждений состоит в том, что вы можете отключить их. Следовательно, в соответствии с этим мнением, вы (почти) никогда не должны использовать утверждения. Я не согласен. Это правда, что если тест относится к производству, вы не должны использовать assert. Но этот тест не относится к производству. Эта ошибка предназначена для обнаружения ошибки, которая вряд ли когда-нибудь достигнет производства, поэтому ее можно безопасно отключить, когда вы закончите.

Кстати, я мог бы написать это так:

assert value == null || value.equals("Y") || value.equals("N") : value;

Это хорошо только для трех значений, но если число возможных значений становится больше, версия HashSet становится более удобной. Я выбрал версию HashSet, чтобы сделать вывод об эффективности.

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

Утверждение работает во время выполнения. Простой пример, который может очень просто объяснить всю концепцию, приведен ниже. Что делает ключевое слово assert в Java? (WikiAnswers).

Утверждения по умолчанию отключены. Чтобы включить их, мы должны запустить программу с -eaпараметрами (степень детализации можно варьировать). Например, java -ea AssertionsDemo.

Существует два формата использования утверждений:

1. Просто: например. assert 1==2; // This will raise an AssertionError,
2. Лучше: assert 1==2: "no way.. 1 is not equal to 2"; это вызовет ошибку AssertionError с отображаемым сообщением, и, следовательно, будет лучше. Хотя фактический синтаксис - это assert expr1:expr2когда expr2 может быть любым выражением, возвращающим значение, я использовал его чаще, просто чтобы напечатать сообщение.

Напомним (и это верно для многих языков, не только Java):

«assert» в основном используется в качестве средства отладки разработчиками программного обеспечения во время процесса отладки. Assert-сообщения никогда не должны появляться. Многие языки предоставляют опцию времени компиляции, которая заставит игнорировать все «утверждения» для использования при генерации «производственного» кода.

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

Кроме того, вызывающим в этой подпрограмме не нужно проверять, успешно ли выполнена подпрограмма: «если бы мы были здесь сейчас, она должна была бы быть успешной, потому что в противном случае она вызвала бы исключение, и мы не были бы здесь сейчас!» Эта простая стратегия значительно упрощает разработку и отладку кода.

Исключения обычно позволяют условиям фатальной ошибки быть такими, как «исключения из правила». И для них должен обрабатываться кодовый путь, который также является «исключением из правила ... » fly ball! »

Утверждения - это проверки, которые могут быть отключены. Они редко используются. Почему?

• Их нельзя использовать для проверки аргументов открытых методов, поскольку вы не можете их контролировать.
• Их не следует использовать для простых проверок, например, result != nullтакие проверки очень быстрые, и вряд ли что-то можно сохранить.

Итак, что осталось? Дорогие чеки на условия действительно ожидаемые, чтобы быть правдой. Хорошим примером будут инварианты структуры данных, такой как RB-дерево. На самом деле, в ConcurrentHashMapJDK8 есть несколько таких значимых утверждений для TreeNodes.

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

Иногда чек не очень дорогой, но в то же время вы уверены, что он пройдет. В моем коде, например,

assert Sets.newHashSet(userIds).size() == userIds.size();

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

В основном, «assert true» пройдет, а «assert false» потерпит неудачу. Давайте посмотрим, как это будет работать:

public static void main(String[] args)
{
    String s1 = "Hello";
    assert checkInteger(s1);
}

private static boolean checkInteger(String s)
{
    try {
        Integer.parseInt(s);
        return true;
    }
    catch(Exception e)
    {
        return false;
    }
}

assertэто ключевое слово. Он был введен в JDK 1.4. Есть два типа assertс

1. Очень простые assertутверждения
2. Простые assertзаявления.

По умолчанию все assertоператоры не будут выполнены. Если assertоператор получает false, он автоматически выдаст ошибку утверждения.