Exception.getMessage() - null

Ответ 1

Вы ловите исключение, отличное от того, которое ваш код явно создает и выдает ¹. Исключение, которое вы ловите, не имеет сообщения. Вы должны регистрировать все исключения, а не только сообщение об исключении. (Среди прочего, это скажет вам, что такое фактический класс перехваченного исключения и где было создано/выброшено исключение.)

Основываясь на том факте, что исключение не имеет сообщения, я предполагаю, что это NPE, вызванное тем, что stud или acc имеет значение null, или stud.getCall() возвращающее null... или что-то в этом роде. NullPointerException сгенерированный изначально (то есть JVM), имеет null сообщение ².

Бросать java.lang.Exception это плохая практика

Ваша проблема показывает, почему вообще нельзя создавать Exception/создавать Exception

Когда вы генерируете Exception становится почти невозможно различить его и другие (неожиданные) исключения в предложении catch. И вот что здесь произошло: вы поймали не то исключение.

Вы должны выбрать более конкретное исключение, и, если оно не существует, внедрите свое собственное.

^{1 - Вы также можете использовать e.printStackTrace(), вызов регистратора или отладчик, чтобы выяснить, какое исключение вы фактически перехватили.}

^{2 - Это не так на Android.Там у NPE есть полезное сообщение, которое дает контекстную информацию.}

Ответ 2

Попробуйте распечатать исключение, а не только сообщение, например

logger.error("caught exception while doing whatever", e);

и посмотреть, что он делает. Печать только сообщения - это рецепт путаницы. Записывая только сообщение, вы выбрасываете трассировку стека с номером строки, указывающим на место, вызвавшее исключение. И теперь вы обнаружили, что не все исключения включают сообщение.

Бросок нового исключения очень плохой, потому что вы выбрасываете исходный тип исключения, а также стек из исходного исключения. Как вы рассчитываете выяснить, что пошло не так, когда вы выбросили всю полезную информацию? Если вы должны поймать исключение, чтобы зарегистрировать его здесь, то снимите то же самое исключение, которое вы поймали, по крайней мере, таким образом вы не потеряете stacktrace. (В качестве альтернативы вы можете создать новое исключение, в котором вы передадите ссылку на исходное исключение в вызове конструктора.)

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

Ответ 3

Вот как я исправил ту же проблему, используйте это, чтобы увидеть исключение:

"" + e);

это поможет вам, когда исходный программист бросил объект Exception без реализации .getMessage();

Я обвиняю Google в разрешении объектов Exception с нулевым getMessage();

когда мой код получал java.lang.NullPointerException это впоследствии привело к сбою моего журнала исключения в e.getMessage();

null из .getMessage(); вызвал у меня еще одно необработанное исключение и разбил приложение с сообщением о закрытии силы. так оно и было:

Log.e("MainLogger.Run.Exception", e.getMessage());

и я изменил его на эту исправленную версию:

Log.e("MainLogger.Run.Exception", "" + e);

теперь он возвращает мне хорошую строку java.lang.NullPointerException

Ответ 4

Поздно вечеринке, но я бы поспорил, что stud имеет значение null, а исключение - NullPointerException в if (stud.getCall()..... Это одно из исключений, которые, как правило, не имеют сообщения, т.е. Null.

Ответ 5

Код кажется точным синтаксисом, а e.getMessage() не должен быть нулевым, я скомпилировал тот же код и напечатал вывод на консоли, который был напечатан как "Some ErrorData is null", который в порядке. Теперь либо проблема с вашим регистратором, либо вы можете найти неправильную строку в файле журнала.

что может быть проблемой с logger

Это полностью зависит от того, какой логгер вы используете? Вы переопределили методы looger.error()? Однако точно, что e.getMessage() не является нулевым в блоке catch. Вы также можете попробовать это, напечатав e.geMessage() на консоли в блоке catch.

Ответ 6

Перед вызовом getMessage() вызовите printStackTrace(). этот метод

записывает печатаемое представление этой трассируемой трассировки стека поток System.err.

try
{
    if (stud.getCall() != null)
        acc.Call = stud.getCall().toString();
    else
        throw new Exception("Data is null");
}
catch (Exception e)
{
    e.printStackTrace();
    logger.error("Some Error" + e.getMessage());
    throw new Exception("Please check the Manatadatory Field is Missing" + e.getMessage());
}

Ответ 7

Надеюсь, это поможет вам....

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

 try{
if (stud.getCall() != null)
    acc.Call = stud.getCall().toString();
else
    throw new DemoClass("Data is null");
}
catch (DemoClass e){
logger.error("Some Error" + e.getMessage());}

и если вы повторно бросаете, то не забудьте указать "throws DemoClass" рядом с вашей функцией (где этот код написан):

 throw new DemoClass("Please check the Mandatory Field is Missing" + e.getMessage());

Ответ 8

Хотел прокомментировать хэмиш "" + e ответить, но мне не хватает очков репутации...

Лучше просто использовать e.toString() вместо "" + e. Результат тот же, но внутренне последний может выполнять больше работы с ненужной конкатенацией, включая создание StringBuilder, добавление пустой строки, добавление результата e.toString() и последующее преобразование обратно в String. См. "3. Оператор сложения" на https://www.baeldung.com/java-strings-concatenation для получения подробной информации об использовании StringBuilder под обложками.

Что касается исходной проблемы, я бы предложил использовать e.getString() (или, что еще лучше, выполнить полную трассировку стека) вместо просто e.getMessage(). Для некоторых исключений сообщение не имеет смысла, не зная тип исключения. Пример, с которым я столкнулся, - это когда e.getMessage() возвращает "-1", но e.toString() возвращает "ArrayIndexOutOfBoundsException: -1". Что бы вы предпочли видеть в своих журналах? :-)