Exception.getMessage() is null

Solution 1:

You are catching a different exception to the one that your code is explicitly creating and throwing¹. The exception that you are catching doesn't have a message.

You need to log the entire exception, not just the exception's message. Among other things, that would tell you what the caught exception's actual class is and where the exception was created/thrown.

Based on the fact that the exception doesn't have a message, I'd guess that it is an NPE caused by stud or acc being null, or by stud.getCall() returning null ... or something like that. A NullPointerException generated natively (i.e. by the JVM) has a null message².

Throwing java.lang.Exception is Bad Practice

Your problem illustrates why it is generally speaking a bad idea to create/throw Exception

When you throw Exception it becomes next to impossible to discriminate between it and other (unexpected) exceptions in a catch clause. And that is what has happened here: you've caught the wrong exception.

You should pick a more specific exception, and if no appropriate one exists, implement one of your own.

^{1 - You could use e.printStackTrace(), a logger call, or a debugger to see which exception you have actually caught.
2 - This is not true on Android. There, an NPE has a helpful message that gives contextual information. It is also no longer true in Java 14 and later; see https://openjdk.java.net/projects/jdk/14/ and https://openjdk.java.net/jeps/358}

Solution 2:

The stack trace is getting written to the log while a message gets written to stdout. My assumption is you don't have permission to see whatever stdout gets written to, so now there is nothing to go on. (Even if you do have rights to see it now you have two separate things to piece together.)

Most logging libraries can log the stacktrace. That way you can keep all the useful information together, adding the exception to the log, not just the message, like

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

The stack trace has the exception message, plus the line number that points to the place that caused the exception, and shows you every call along the way, so it's really helpful. And now you've found out not all exceptions include a message.

If whatever you are logging to doesn't handle writing the exception stack trace information, there is code to write the stacktrace as a string here.

The way the posted code throws a new exception is very bad, because you are throwing away the original type of the exception, plus the stacktrace of the original exception. How do you expect to figure out what went wrong when you throw away all the helpful information? If you must catch the exception to log it here, then rethrow the same exception that you caught, or pass the original exception to the new exception as the cause (check out the Throwable constructor arguments), at least that way you don't lose the stacktrace.

You would be better off using a centralized exception handler, letting that do the logging, and have unexpected exceptions go uncaught until they get to the handler. Because once something throws an unexpected exception, your application is in a bad state, any subsequent steps that rely on something this part was supposed to do will fail, and you will get a cascade of errors.

Solution 3:

This is how I fixed the same problem, use this to see the exception:

"" + e);

this will help you when the original programmer threw an Exception object without implementing .getMessage();

I blame Google for allowing Exception objects with null getMessage();

when my code was getting a java.lang.NullPointerException it was subsequently causing my exception logging to fail on e.getMessage();

the null from .getMessage(); caused me another unhandled exception and crashed the app with force close message. so it was this:

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

and I changed it to this Corrected version:

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

now it gives me a nice string returned java.lang.NullPointerException