Когда поймать java.lang.Error?

голоса
101

В каких ситуациях следует один поймать java.lang.Errorна приложение?

Задан 09/12/2008 в 14:56
источник пользователем
На других языках...                            


16 ответов

голоса
87

Вообще, никогда. Тем не менее, иногда вам нужно поймать конкретные ошибки.

Если вы пишете рамки-иш код (загрузка 3-го классов партии), было бы целесообразно, чтобы поймать LinkageErrors (не класс четкости найдено, неудовлетворенный ссылку, несовместимые изменения класса). Я также видел, какой-то дурацкий код третьих стороной метание sublcasses ошибок, так что вы будете работать с ними либо.

Кстати, я не уверен, что это не возможно, чтобы оправиться от OutOfMemory.

Ответил 09/12/2008 в 15:12
источник пользователем

голоса
46

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

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

Ответил 09/12/2008 в 15:00
источник пользователем

голоса
16

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

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

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

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

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

Например:

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

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

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

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

Ответил 05/03/2009 в 13:29
источник пользователем

голоса
14

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

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

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

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

Ответил 07/03/2009 в 17:39
источник пользователем

голоса
7

Очень редко.

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

Если вы в структуре, которая делает такого рода вещи для вас, оставьте его в рамки.

Ответил 09/12/2008 в 15:15
источник пользователем

голоса
6

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

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

Ответил 10/12/2008 в 21:44
источник пользователем

голоса
6

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

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

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

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

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

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

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

Ответил 09/12/2008 в 15:18
источник пользователем

голоса
6

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

Ответил 09/12/2008 в 14:59
источник пользователем

голоса
5

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

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

Ответил 09/12/2008 в 15:09
источник пользователем

голоса
4

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

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

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

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

Ответил 09/12/2008 в 15:28
источник пользователем

голоса
3

это очень удобно, чтобы поймать java.lang.AssertionError в тестовой среде ...

Ответил 27/11/2013 в 02:53
источник пользователем

голоса
3

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

  • Старейшая поддерживаются SDK может измениться в будущем для конкретной библиотеки
  • Блок ошибок примерки улова является частью более крупного падения назад механизма. Некоторые конкретные устройства, хотя они должны поддерживать библиотеку, бросать исключения. Я ловлю VerifyError и все исключения использовать раствор обратно осенью.
Ответил 14/03/2013 в 07:17
источник пользователем

голоса
2

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

Ответил 05/05/2014 в 19:22
источник пользователем

голоса
1

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

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

Вы также понижаем читаемость кода.

Ответил 23/04/2013 в 17:50
источник пользователем

голоса
1

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

Ответил 19/08/2012 в 21:35
источник пользователем

голоса
1

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

Ответил 26/01/2011 в 07:23
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more