Коли ловити java.lang.Error?

У яких ситуаціях слід потрапити java.lang.Errorна додаток?

Взагалі ніколи.

Однак іноді потрібно ловити конкретні помилки.

Якщо ви пишете фреймворк-код (завантаження сторонніх класів), це може бути розумно зловити LinkageError(не знайдено визначення класу, незадовільне посилання, несумісні зміни класу).

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

До речі, я не впевнений, що від цього неможливо відновитись OutOfMemoryError.

Ніколи. Ви ніколи не можете бути впевнені, що програма зможе виконати наступний рядок коду. Якщо ви отримаєте OutOfMemoryError, у вас немає гарантії, що ви зможете зробити щось надійно . Ловіть RuntimeException і перевіряйте винятки, але ніколи не помилки.

http://pmd.sourceforge.net/rules/strictexception.html

Як правило, ви завжди повинні їх ловити java.lang.Errorта записувати до журналу або демонструвати користувачеві. Я працюю в підтримку і щодня бачу, що програмісти не можуть розповісти, що сталося в програмі.

Якщо у вас є демонова нитка, ви повинні запобігти її припиненню. В інших випадках ваша програма працюватиме коректно.

Ви повинні ловити лише java.lang.Errorна найвищому рівні.

Якщо ви подивитесь на список помилок, ви побачите, що більшість з них можна впоратися. Наприклад, ZipErrorвиникає при читанні пошкоджених поштових файлів.

Найбільш поширені помилки - це, OutOfMemoryErrorі NoClassDefFoundErrorвони в більшості випадків є проблемами виконання.

Наприклад:

int length = Integer.parseInt(xyz);
byte[] buffer = new byte[length];

може спричинити, OutOfMemoryErrorале це проблема часу виконання і немає причин припиняти програму.

NoClassDefFoundErrorвиникають здебільшого, якщо бібліотеки немає або якщо ви працюєте з іншою версією Java. Якщо це додаткова частина вашої програми, ви не повинні припиняти програму.

Я можу навести ще багато прикладів того, чому це гарна ідея піти Throwableна найвищому рівні та створити корисне повідомлення про помилку.

У багатопотоковому середовищі ви найчастіше хочете його зловити! Коли ви його впіймаєте, запишіть його та закрийте всю програму! Якщо цього не зробити, якась нитка, яка може зробити якусь важливу частину, буде мертвою, а решта програми вважатиме, що все нормально. З цього може трапитися багато небажаних ситуацій. Одна з найменших проблем полягає в тому, що ви не зможете легко знайти корінь проблеми, якщо інші потоки почнуть викидати деякі винятки через те, що одна нитка не працює.

Наприклад, зазвичай цикл повинен бути:

try {
   while (shouldRun()) {
       doSomething();
   }
}
catch (Throwable t) {
   log(t);
   stop();
   System.exit(1);
}

Навіть у деяких випадках ви хочете по-різному обробляти різні помилки, наприклад, на OutOfMemoryError ви зможете регулярно закривати додаток (навіть, можливо, звільнити деяку пам’ять і продовжувати), а в деяких інших - зробити це не так вже й багато.

Дуже рідко.

Я б сказав лише на верхньому рівні потоку для того, щоб ATTEMPT видав повідомлення з причиною відмирання потоку.

Якщо ви знаходитесь в рамках, який робить для вас подібні речі, залиште це рамки.

Майже ніколи. Помилки створені як проблеми, з якими програми зазвичай нічого не можуть зробити. Єдиним винятком може слугувати подання помилки, але навіть це може бути не так, як планувалося залежно від помилки.

ErrorЗазвичай не повинні бути спіймані , оскільки це вказує на ненормальний стан , який ніколи не повинен статися .

З специфікації Java API для Errorкласу:

Це Errorпідклас, Throwable який вказує на серйозні проблеми, які розумне застосування не повинно намагатися наздогнати. Більшість таких помилок - це ненормальні умови. [...]

Метод не зобов’язаний оголошувати в пункті кидок будь-які підкласи помилки, які можуть бути кинуті під час виконання методу, але не виявлені, оскільки ці помилки - це аномальні умови, які ніколи не повинні виникати.

Як зазначається в специфікації, анкета Errorкидається лише в обставинах, які є, Швидше за все, якщо програма Errorтрапляється, програма може зробити дуже мало, а в деяких випадках сама віртуальна машина Java може перебувати в нестабільному стані (наприклад, VirtualMachineError)

Хоча an Errorє підкласом, Throwableщо означає, що він може бути зафіксований try-catchпунктом, але він, ймовірно, насправді не потрібен, оскільки додаток буде в ненормальному стані, коли Errorкидок буде переданий JVM.

Там також короткий розділ по цій темі в розділі 11.5 Ієрархія винятків з специфікації мови Java, 2nd Edition .

Якщо ви досить божевільні, щоб створити нову рамку тестування модуля, ваш тестовий бігун, ймовірно, повинен буде зловити java.lang.AssertionError, кинутий будь-якими тестовими кейсами.

В іншому випадку дивіться інші відповіді.

І є кілька інших випадків, коли якщо ви потрапили на помилку, вам доведеться її повторно скинути . Наприклад, ThreadDeath ніколи не повинен бути спійманий, це може спричинити велику проблему, якщо ви його зловите в умовах, що міститься (наприклад, сервер програми):

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

Дуже, дуже рідко.

Я робив це лише для одного дуже конкретного відомого випадку. Наприклад, java.lang.UnsatisfiedLinkError може бути кинутим, якщо два незалежність ClassLoader завантажують ту саму DLL. (Я згоден, що я повинен перемістити JAR до спільного завантажувача класів)

Але найпоширеніший випадок - це те, що вам потрібен був журнал, щоб знати, що сталося, коли користувач прийшов скаржитися. Ви хочете, щоб повідомлення або спливаюче вікно для користувача, а не мовчки мертві.

Навіть програміст на C / C ++, вони виявляють помилку і повідомляють те, що люди не розуміють, перш ніж вона вийде (наприклад, поломка пам'яті).

У додатку для Android я ловлю java.lang.VerifyError . Бібліотека, яку я використовую, не працюватиме на пристроях зі старою версією ОС, і код бібліотеки видасть таку помилку. Я, звичайно, міг уникнути помилки, перевіривши версію ОС під час виконання, але:

• Найстаріший підтримуваний SDK може змінитися в майбутньому для конкретної бібліотеки
• Блок помилок спроб уловлювання є частиною більшого механізму відхилення. Деякі конкретні пристрої, хоча вони мають підтримувати бібліотеку, викидають винятки. Я ловлю VerifyError та всі винятки, щоб використовувати рішення із зворотного зв'язку.

досить зручно ловити java.lang.AssertionError у тестовому середовищі ...

В ідеалі ми не повинні обробляти / вловлювати помилки. Але можуть бути випадки, коли нам це потрібно робити, виходячи з вимог рамки чи застосування. Скажімо, у мене демон XML Parser, який реалізує DOM Parser, який споживає більше пам'яті. Якщо є така вимога, як нитка Parser, не слід загинути, коли вона отримує OutOfMemoryError , замість цього вона повинна обробляти її та надсилати повідомлення / пошту адміністратору програми / фреймворку.

в ідеалі ми ніколи не повинні вловлювати помилку в нашому додатку Java, оскільки це ненормальне стан. Застосування буде в ненормальному стані і може призвести до зачистки або отримання серйозно неправильного результату.

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

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

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

Ви також зменшите читабельність свого коду.