Що робить ключове слово Java assert і коли його слід використовувати?

Наведіть кілька прикладів із реального життя, щоб зрозуміти ключову роль тверджень?

У Java 1.4 додано твердження (за допомогою ключового слова assrt ). Вони використовуються для перевірки правильності інваріанта в коді. Вони ніколи не повинні спрацьовувати у виробничому коді, вони є вказівкою на помилку чи неправильне використання кодового шляху. Вони можуть бути активовані під час виконання за допомогою -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 не є мовою, яку можна перевірити, це означає: ви не можете підрахувати, що результат вашої операції буде ідеальним. Основною причиною цього є покажчики: вони можуть вказувати куди-небудь або ніде, тому їх не можна обчислити таким саме значенням, принаймні, не в межах розумного діапазону коду. Враховуючи цю проблему, немає ніякого способу довести, що ваш код взагалі правильний. Але те, що ти можеш зробити, це довести, що ти принаймні знаходиш кожну помилку, коли вона трапляється.

Ця ідея заснована на парадигмі « Дизайн за контрактом» (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 - це схоже поняття, але вони не можуть все перевірити. Якщо ви хочете ще більше перевірок (ціною швидкості виконання), вам потрібно використовувати твердження. Це призведе до розмивання вашого коду, але ви, зрештою, зможете доставити продукт на дивно короткий час розробки (чим раніше ви виправите помилку, тим нижча вартість). І крім того: якщо у вашому коді є якась помилка, ви її виявите. Неможливо проскочити помилку і викликати проблеми пізніше.

Це все ще не є гарантією безпроблемного коду, але він набагато ближче до цього, ніж звичайні програми.

Твердження - це інструмент на фазі розробки для лову помилок у вашому коді. Вони розроблені для того, щоб їх легко видалити, тому їх не буде існувати у виробничому коді. Тож твердження не є частиною «рішення», яке ви доставляєте замовнику. Вони проводять внутрішні перевірки, щоб переконатися, що припущення, які ви робите, правильні. Найпоширеніший приклад - тестування на null. Багато методів написано так:

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()методу в тому випадку, коли цеValue не є нульовим. Але він передбачає, що 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але завжди включайте твердження у виробництво. Справді, це те, що я прагну робити. Я наполягаю на примітці на ломбок, яка змусить assertдіяти більше схоже if (...) throw .... Голосуйте за це тут.

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

Ось найпоширеніший випадок використання. Припустимо, ви перемикаєте значення перерахунку:

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

Поки ти розбираєшся у кожному випадку, ти добре. Але коли-небудь хтось додасть фігу до вашого перерахунку і забуде додати його до вашої заяви переключення. Це призводить до появи помилки, яка може виявити складність, оскільки ефекти не будуть відчуватися, поки ви не залишите оператор перемикання. Але якщо ви запишете свій перемикач так, ви можете його зловити негайно:

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()в an 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в командному рядку та throw new AssertionError().

Справжній приклад із класу Stack (з твердження в статтях Java )

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

Затвердження дозволяє виявити дефекти коду. Ви можете увімкнути твердження про тестування та налагодження, залишаючи їх вимкнутими, коли ваша програма працює.

Навіщо стверджувати щось, коли знаєш, що це правда? Це правда лише тоді, коли все працює належним чином. Якщо програма має дефект, це може бути насправді неправдою. Виявлення цього раніше в процесі дає вам знати, що щось не так.

assertЗаява містить цю заяву разом з додатковим Stringповідомленням.

Синтаксис твердження про твердження має дві форми:

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" або null, яке трактувалося як "N". Ми хочемо переконатися, що клієнт браузера обмежений цими трьома значеннями. Отже, у своїх сетерах для цих двох властивостей я додав це твердження:

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

Зауважте наступне.

1. Це твердження стосується лише фази розвитку. Якщо клієнт надішле погану цінність, ми зловимо це рано і виправимо його, задовго до того, як досягти виробництва. Твердження стосуються дефектів, які можна зловити рано.

2. Це твердження повільне та неефективне. Нічого страшного. Твердження можуть бути повільними. Нас це не хвилює, оскільки це лише інструменти для розробки. Це не уповільнить виробничий код, оскільки твердження будуть відключені. (Є певна незгода з цього приводу, про яку я пізніше піде.) Це призводить до мого наступного моменту.

3. Це твердження не має побічних ефектів. Я міг би перевірити свою цінність на незмінюваному статичному фінальному наборі, але цей набір залишився б у виробництві, де він ніколи не звикне.

4. Це твердження існує для перевірки правильної роботи клієнта. Тож до моменту, коли ми досягнемо виробництва, ми будемо впевнені, що клієнт працює належним чином, тому ми можемо сміливо вимкнути твердження.

5. Деякі люди запитують це: Якщо твердження не потрібне у виробництві, чому б просто не вийняти їх, коли закінчите? Тому що вони все ще знадобляться, коли ви почнете працювати над наступною версією.

Деякі люди стверджують, що ви ніколи не повинні використовувати твердження, оскільки ви ніколи не можете бути впевнені, що всі помилки зникли, тому вам потрібно тримати їх навколо навіть у виробництві. І тому використовувати сенс твердження не має сенсу, оскільки єдиною перевагою тверджень є те, що ви можете їх вимкнути. Отже, відповідно до цього мислення, ви (майже) ніколи не повинні використовувати твердження. Я не погоджуюсь. Безумовно, правда, що якщо тест належить до виробництва, не слід використовувати твердження. Але цей тест не належить до виробництва. Це - для вилову помилки, яка, ймовірно, ніколи не досягне виробництва, тому її можна безпечно вимкнути, коли закінчите.

До речі, я міг би написати це так:

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" в основному використовується як налагоджувальна програма розробниками програмного забезпечення в процесі налагодження. Сертифікатні повідомлення ніколи не повинні з’являтися. Багато мов пропонують час компіляції, що призведе до ігнорування всіх "тверджень" для використання при створенні "виробничого" коду.

"Винятки" - це зручний спосіб вирішення будь-яких умов помилок, незалежно від того, представляють вони логічні помилки чи ні, оскільки, якщо ви зіткнетесь з умовою помилки, такою, що не можете продовжуватись, ви можете просто "кинути їх у повітря, "звідки б ви не були, очікуючи, що хтось там буде готовий" зловити "їх. Управління передається в один крок прямо від коду, який кинув виняток, прямо до рукавиці лову. (І видовище може побачити повний зворотній зв'язок, що відбувся.)

Крім того, абоненти цієї підпрограми не повинні перевіряти, чи вдалася підпрограма: "якщо ми зараз тут, то, мабуть, це вдалося, тому що в іншому випадку вона б кинула виняток, і ми зараз не були б тут!" Ця проста стратегія значно спрощує розробку коду та налагодження.

Винятки зручно дозволяють умовам фатальної помилки бути такими, якими вони є: "винятки з правила". І, щоб вони обробляли кодовий шлях, який також є "винятком із правила ... " мухоловка! "

Твердження - це перевірки, які можуть бути відключені. Вони рідко використовуються. Чому?

• Вони не повинні використовуватися для перевірки аргументів публічного методу, оскільки ви не маєте контролю над ними.
• Вони не повинні використовуватися для простих перевірок, як- result != nullот такі перевірки дуже швидкі і навряд чи є що врятувати.

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

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

Іноді чек насправді не дорогий, але в той же час, ти майже впевнений, він пройде. У моєму коді є, наприклад,

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

де я майже впевнений, що список, який я щойно створив, має унікальні елементи, але я хотів його документувати та ще раз перевірити.

В основному "стверджувати істину" пройде, а "стверджувати помилкове" не вдасться. Давайте розглянемо, як це буде працювати:

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. Є два типи asserts

1. Дуже прості assertзаяви
2. Прості assertзаяви.

За замовчуванням всі assertзаяви не виконуватимуться. Якщо assertвислів отримає помилкове значення, воно автоматично призведе до помилки твердження.