Нет-бросок VirtualMachineError гарантирует - PullRequest
13 голосов
/ 04 января 2012

Я пришел на Java из C ++.В мире C ++ мы обращаем внимание на безопасность исключений и отмечаем, что мутаторы могут предоставлять различные гарантии перед лицом исключений, создаваемых самим мутатором или методом, которому он делегирует (минимальный, сильный, безбросочный).Реализация метода, который имеет строгую гарантию исключений, требует, чтобы некоторые базовые операции гарантированно никогда не генерировали исключение.JLS делает заявления о том, какие операции могут генерировать какие исключения, но ошибка VirtualMachineError представляет проблему.Не исключено, что JLS :

из-за внутренней ошибки или ограничения ресурсов виртуальная машина Java не позволяет реализовать семантику языка программирования Java;в этом случае создается экземпляр подкласса VirtualMachineError.

JLS больше не говорит о VirtualMachineError.«Внутренняя ошибка» означает ошибку в JVM, поэтому я не заинтересован в этом случае: перед лицом ошибок в JVM все ставки отключены.Но как насчет дела об ограничении ресурсов?Существуют ли какие-либо операции, которые гарантированно никогда не завершатся неудачей из-за ограниченности ресурсов?

Ответы [ 4 ]

13 голосов
/ 04 января 2012

Спецификация виртуальной машины Java :

Эта спецификация не может предсказать, где могут возникнуть внутренние ошибки или ограничения ресурсов, и не определяет точно, когда о них можно сообщить.Таким образом, любой из VirtualMachineError подклассов, определенных ниже, может быть сгенерирован в любой момент во время работы виртуальной машины Java:

Поэтому в Java не может быть никаких исключений в отношенииVirtualMachineError исключения .Все исключения должны быть предметом квалификации "... но не в случае выброса VirtualMachineError".Это один из способов отличия Java от C ++.

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

1 голос
/ 04 января 2012

Я вижу, что вы ответили на свой вопрос, и я могу понять, почему это будет вас слегка удивлять, если исходить из строгого C ++ фона.Это просто реальность управляемой памяти (виртуальных) машин, и она не ограничивается только Java.Память может исчерпаться, поскольку JVM ограничена тем, сколько кучи она может использовать (настраивается в командной строке java).

Несколько аналогично, но не эквивалентно, в мире C ++ / машинного кодаGENERAL_PROTECTION_FAULT (или SEGMENTATION_FAULT, если вы используете * NIX), который вы получите при попытке адресации памяти, которая не была выделена или находится за пределами вашего виртуального адресного пространства.Предоставление «строгой гарантии исключений» перед лицом такого сценария одинаково сложно, поскольку причиной может быть либо ошибка в коде, либо полная неуправляемость программы.

1 голос
/ 04 января 2012

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

Эта ошибка не похожа на OutofMemoryError, где к этому времени могут выполняться некоторые операции.

0 голосов
/ 04 января 2012

В Java вы можете вызывать Thread.stop () или stop (Throwable) в любое время.Большинство ошибок считаются настолько критичными, что вам не следует пытаться их обрабатывать, если вы действительно не знаете, что делаете.

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

Можете ли вы привести пример того, почему вы считаете, что вам нужна гарантия, поскольку, скорее всего, существует другой способ решения проблемы?

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