Причины получения java.lang. VerifyError
6 ответов
java.lang.VerifyError может быть результатом, когда вы скомпилировали с другой библиотекой, чем вы используете во время выполнения.
Например, это случилось со мной, когда я пытался запустить программу, которая была скомпилирована для Xerces 1, но Xerces 2 был найден в пути к классам. Требуемые классы (в пространстве имен org.apache. * ) были найдены во время выполнения, поэтому ClassNotFoundException было не результатом. Были внесены изменения в классы и методы, так что сигнатуры методов, обнаруженные во время выполнения, не соответствовали тому, что было во время компиляции.
Обычно компилятор помечает проблемы, в которых сигнатуры методов не совпадают. JVM снова проверит байт-код при загрузке класса и выдает VerifyError , когда байт-код пытается сделать что-то, что не должно быть разрешено - например, вызов метода, который возвращает String , а затем сохраняет это возвращаемое значение в поле, содержащем List .
Эта страница может дать Вам некоторые подсказки - http://www.zanthan.com/itymbi/archives/000337.html
может быть тонкая ошибка в теле того метода, который javac не удается определить. Трудный диагностировать, если Вы не отправляете целый метод здесь.
Вы могли запустить путем объявления как можно большего количества переменных как финала..., который поймает ошибку, упомянутую на zanthan сайте, и часто является хорошей практикой так или иначе.
Одна вещь, которую Вы могли бы попробовать, использует -Xverify:all, который проверит байт-код на загрузке и иногда дает полезные сообщения об ошибках, если байт-код будет недопустим.
java.lang.VerifyError хуже.
Вы получили бы эту ошибку, если размер байт-кода Вашего метода превышает предел 64 КБ; но Вы, вероятно, заметили бы это.
Вы 100%, уверенных, что этот класс не присутствует в пути к классу в другом месте в Вашем приложении, возможно, в другой банке?
кроме того, от Вашего stacktrace, кодировка символов исходного файла (utf-8?), Который корректен?
У меня возникла эта проблема из-за того, что pack200 искажал файл класса. Небольшой поиск исправил эту ошибку java . По сути, установка - усилия = 4 вызвала исчезновение проблемы.
Использование java 1.5.0_17 (хотя оно возникало в каждом отдельном варианте java 1.5, в котором я его пробовал).
Возможно, вы сможете гарантировать, что ваш код не вызовет исключение сегодня, но как быть, когда вы вернетесь к нему через 6 месяцев? Или кто-то другой должен внести изменения?
Использование блока наконец является признанным образцом, который будет иметь смысл для любого программиста, если ваш код делает что-то особенное и другое, он приведет вас или кого-то еще вверх.
Во втором случае контроль дойдет до S2, только если вы проглотите любое исключение, когда-либо попавшее в ловушку! Try-Catch следует использовать не здесь и там, а осторожно.
Ex:
try
{
// Do something that might throw
}
catch (Exception ex)
{
// Save the exception to re-throw later
// NB: This statement cannot throw an exception!
// this.cachedException = ex;
// Must swallow any exception here to let control go further!
// If you're not sure enough [which you and me both are not likely to be] - use finally to execute S2 in any condition
}
// No finally block needed (?)
S2;
S3;
VerifyError означает, что файл класса содержит синтаксически правильный байт-код, но нарушает некоторые семантические ограничения, например, цель перехода, которая пересекает границы метода.
В основном, VerifyError может возникать только при наличии ошибки компилятора или при повреждении файла класса каким-либо другим способом (например, через неисправную оперативную память или неисправную HD-память).
Попробуйте выполнить компиляцию с другой версией JDK и на другом компьютере.