Вопрос по Java.lang.Error - PullRequest
       21

Вопрос по Java.lang.Error

3 голосов
/ 30 августа 2010

На java.lang.Error много сообщений о том, что это не должно быть поймано.У меня вопрос: не стоит ли быть осторожным с тем, что толку от этого.Так как это Throwable, чтобы мы могли поймать его в try catch.Я читаю некоторые посты, как будто только в какой-то ситуации это нужно поймать, как узнать эти ситуации.

Короче говоря, я хочу знать, что может пойти не так, когда я поймаю Error.Что за этим стоит процесс.Почему они сделали ошибку и ее подклассы?Если мое приложение не должно их ловить, то что их ловит?Почему мой код не может обработать эту пойманную ошибку?Если я просто поймаю одну ошибку и напишу некоторый код обработки в блоке Catch, будет ли этот код выполняться?

Ответы [ 3 ]

1 голос
/ 30 августа 2010

Ошибка (особенно подкласс VirtualMachineError) указывает на то, что JVM обнаружила внутреннюю проблему - такую, которая означает, что ее внутреннее состояние больше не может быть согласованным. Если вы обнаружите ошибку и попытаетесь восстановить ее, поведение в будущем не определено. Причина, по которой ошибки являются Throwable, заключается в том, что они могут быть выброшены - например, вы можете сделать это самостоятельно для ошибок в собственной библиотеке, из которой невозможно восстановить данные (например, библиотека могла записать в память JVM или повредить свое внутреннее статическое состояние ). В случае всех Throwables используется одно и то же оборудование для ходьбы и получения стека - было бы глупо иметь другой механизм, который бы делал то же самое.

Большинство ошибок в JVM, которые не являются VirtualMachineErrors, представляют собой ситуации, когда собственная библиотека могла повредить свое статическое состояние - например, AWTError, ZipError.

Однако в некоторых редких случаях обнаружение ошибки является нормальным: AssertionError в инфраструктуре тестирования и LinkageError, где вам приходится иметь дело с отсутствием / наличием различных версий библиотек во время выполнения. Это довольно редкое требование, и с ним можно лучше справиться через рефлексию.

1 голос
/ 30 августа 2010

Все правила имеют исключения (кроме этого).

Даже если все говорят, что вы не должны этого делать, существует множество случаев, когда вполне уместно поймать эти java.lang.Error. Логика, лежащая в основе правила, гласила: «не пытайтесь продолжать работу приложения после обнаружения фатального состояния». Поэтому вы должны быть осторожны, прежде чем делать что-то после появления такой ошибки. Вполне возможно, что система не сможет продолжить свою задачу после этого.

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

  1. Исправление ошибок программирования (AssertionError, StackOverflowError)
  2. Исправление ошибок конфигурации (UnsatisfiedLinkError)
  3. Исправить параметры размера JVM (OutOfMemoryError)

Этот тип обработки должен выполняться очень "высоко" в стеке вызовов (то есть рядом с main ()), где выполняется основной цикл (или эквивалентный). Я думаю, что не рекомендуется перехватывать Error в глубоком коде, в этих случаях вы должны хотя бы сбросить ошибку.

0 голосов
/ 30 августа 2010

Подобный вопрос уже дан ответ здесь - Когда ловить java.lang.Error?

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

...