Является ли это возможным? В каком сценарии могут быть выброшены такие унифицированные исключения??
Это невозможно при использовании совместимого компилятора Java и совместимой виртуальной машины Java, а также соответствующей Виртуальная машина Dalvik. JLS не позволяет переменной e быть null в этом месте.
Либо у вас глючит виртуальная машина, глючит отладчик, либо проблема с вашей IDE, инструментами сборки и/или процессом.
Если бы я был в вашей ситуации, я бы пока прекратил использовать отладчик и вернулся к добавлению в ваш код устаревших отпечатков трассировки. И убедитесь, что вы делаете чистую и полную сборку из исходного кода.
Еще одна возможность, которую следует учитывать, заключается в том, что номера строк, о которых JRE сообщает во время выполнения (и на которые полагается отладчик), не совпадают с номерами строк в исходном коде. Это может произойти, если вы допустили ошибку в процессах сборки и развертывания. Ошибка может заключаться в том, что вы забыли сохранить файл, забыли собрать, забыли развернуть новую версию приложения или рассинхронизировали IDE с файловой системой.
Что бы это ни стоило, теория состоит в том, что это вызвано throw null; или чем-то эквивалентным, не выдерживает критики. В разделе JLS 14.18 говорится:
"Если вычисление Expression завершается нормально и дает нулевое значение, то экземпляр V' класса NullPointerException создается и генерируется вместо null."
Это легче понять, если вы прочитаете это предложение в его контексте, но оно ясно говорит о том, что throw null; на самом деле выдает NullPointerException.
ОБНОВЛЕНИЕ
Я нашел другое правдоподобное объяснение в этом вопросе о переполнении стека: Exception всегда NULL
По сути, это говорит о том, что эмулируемый код генерирует исключение, о котором Eclipse не знает, а эмулятор Eclipse «услужливо» заменяет null. Похоже на баг эмулятора.
person
Stephen C
schedule
06.12.2011
