Когда поймать java.lang. Ошибка?

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

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

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

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

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

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

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

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

Error подкласс Throwable, который указывает на серьезные проблемы, которые разумное приложение не должно пытаться поймать. Большинство таких ошибок является ненормальными условиями. [...]

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

, Поскольку спецификация упоминает, Error только брошен в обстоятельства, которые являются Возможностями, когда Error происходит, существует очень мало приложение, может сделать, и при некоторых обстоятельствах, сама виртуальная машина Java может быть в нестабильном состоянии (такой как [1 112] VirtualMachineError )

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

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

Очень редко.

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

, Если Вы находитесь в платформе, которая делает этот вид вещи для Вас, оставьте это платформе.

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

, Например, обычно цикл должен быть:

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

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

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

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

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

Иначе, см. другие ответы.

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

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

Необходимо только поймать java.lang.Error на высшем уровне.

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

Наиболее распространенные ошибки OutOfMemoryError и NoClassDefFoundError, которые являются оба в большинстве случаев проблемами во время выполнения.

Например:

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

может произвести OutOfMemoryError но это - проблема во время выполнения и никакая причина завершить Вашу программу.

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

Я могу дать намного больше примеров того, почему это - хорошая идея поймать Throwable на верхнем уровне и производят полезное сообщение об ошибке.