Когда ловить java.lang.Error?

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

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

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

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

An application should catch instances of this class only if it must clean up after being terminated asynchronously. If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.

В общем, никогда.

Однако иногда нужно отлавливать конкретные ошибки.

Если вы пишете фреймворк-код (загружаете сторонние классы), было бы разумно поймать LinkageError (определение класса не найдено, неудовлетворенная ссылка, несовместимое изменение класса).

Я также видел, как какой-то тупой сторонний код генерирует подклассы Error, так что вам придется справиться и с ними.

Кстати, я не уверен, что восстановление с OutOfMemoryError невозможно.

Очень редко.

Я бы сказал, только на верхнем уровне потока, чтобы ПОПЫТАТЬСЯ выдать сообщение с причиной смерти потока.

Если вы работаете во фреймворке, который делает это за вас, оставьте это фреймворку.

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

Из спецификации Java API для класса Error:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. [...]

A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.

Как указано в спецификации, Error бросается только в тех случаях, когда Скорее всего, когда происходит Error, приложение мало что может сделать, и в некоторых обстоятельствах сама виртуальная машина Java может находиться в нестабильном состоянии (например, VirtualMachineError).

Хотя Error является подклассом Throwable, что означает, что он может быть перехвачен предложением try-catch, но, вероятно, в этом нет необходимости, поскольку приложение будет находиться в ненормальном состоянии, когда JVM выбрасывает Error.

Также есть небольшой раздел по этой теме в разделе 11.5 Иерархия исключений документа Спецификация языка Java, 2-е издание.

Очень-очень редко.

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

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

Даже программист на C / C++ выдает сообщение об ошибке и сообщает что-то, чего люди не понимают, прежде чем она завершится (например, сбой памяти).

Если вы достаточно сумасшедшие, чтобы создавать новую среду модульного тестирования, вашему исполнителю тестов, вероятно, потребуется отловить java.lang.AssertionError, выдаваемый любыми тестовыми примерами.

В противном случае смотрите другие ответы.

Как правило, вы всегда должны ловить java.lang.Error и записывать его в журнал или отображать его пользователю. Я работаю в службе поддержки и ежедневно вижу, что программисты не могут сказать, что произошло в программе.

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

Вы должны ловить java.lang.Error только на самом высоком уровне.

Если вы посмотрите на список ошибок, вы увидите, что с большинством из них можно справиться. Например, ZipError возникает при чтении поврежденных zip-файлов.

Наиболее частыми ошибками являются 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 вы сможете регулярно закрывать приложение (даже, возможно, освободить некоторую память и продолжить), в некоторых других вы мало что можете сделать.

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

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

В приложении для Android я ловлю java.lang.VerifyError. Библиотека, которую я использую, не будет работать на устройствах со старой версией ОС, и код библиотеки выдаст такую ​​ошибку. Конечно, я мог бы избежать ошибки, проверив версию ОС во время выполнения, но:

• Самый старый поддерживаемый SDK может измениться в будущем для конкретной библиотеки.
• Блок ошибки try-catch является частью более крупного механизма отката. Некоторые конкретные устройства, хотя они должны поддерживать библиотеку, выдают исключения. Я ловлю VerifyError и все исключения, чтобы использовать запасное решение.

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

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

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

очень удобно ловить java.lang.AssertionError в тестовой среде ...

В идеале мы не должны обрабатывать / отлавливать ошибки. Но могут быть случаи, когда нам нужно это сделать, исходя из требований фреймворка или приложения. Скажем, у меня есть демон XML Parser, который реализует Парсер DOM, который потребляет больше памяти. Если есть требование, например, поток парсера не должен умирать, когда он получает OutOfMemoryError, вместо этого он должен обработать его и отправить сообщение / письмо администратору приложения / фреймворка.