java – Exception.getMessage() is null-ThrowExceptions

Exception or error:

Inside my Java code, it is checking for !null condition and throwing an Exception.

For example

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

But in the logs I am getting:

Some Error null

Why is the e.getMessage null?

How to solve:

You are catching an exception other than the one that your code is explicitly creating and throwing1. 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 message2.


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 also use e.printStackTrace(), a logger call, or a debugger to find out which exception you have actually caught.

2 – This is not true on Android. There, an NPE has a helpful message that gives contextual information.

Answer:

Try printing the exception, not just the message, like

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

and see what it does. Printing just the message is a recipe for confusion. By recording only the message you are throwing away the stack trace with the line number that points to the place that caused the exception. And now you’ve found out not all exceptions include a message.

Throwing the 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, at least that way you don’t lose the stacktrace. (Alternatively you can throw a new exception where you pass in a reference to the original exception in the constructor call.)

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.

Answer:

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

Answer:

This is late to the party but I’d bet stud is null and the exception you get is NullPointerException at if (stud.getCall()..... It’s one of the exception that tend not to have message, i.e. null.

Answer:

Wanted to comment on hamish’s "" + e answer but I don’t have enough reputation points…

It’s better to just use e.toString() instead of "" + e. The result is the same, but internally, the latter may be doing more work with unnecessary concatenation, involving creating a StringBuilder, appending the blank string, appending the result of e.toString() then converting back to a String. See “3. Addition Operator” of https://www.baeldung.com/java-strings-concatenation for details about StringBuilder being used under the covers.

Regarding the original problem, I’d suggest using e.getString() (or even better, do a full stack trace) instead of just e.getMessage(). For some exceptions the message doesn’t make sense without knowing the exception type. An example I’ve encountered is where e.getMessage() returns “-1”, but e.toString() returns “ArrayIndexOutOfBoundsException: -1”. Which would you prefer to see in your logs? 🙂

Answer:

The code seems fine syntax wise and e.getMessage() should not be null, I compiled the same code and printed the output on console, it printed as "Some ErrorData is null" which is fine. Now either there is issue with your logger or you might be looking at the wrong line in logger file.

what can be the issue with logger

It completely depends upon which logger are you using ? Have you overridden the methods of looger.error() ? However it is for sure that e.getMessage() is not null in the catch block. You can also try that by printing e.geMessage() on console in the catch block.

Answer:

Before call getMessage() call printStackTrace(). this method

writes a printable representation of this Throwable’s stack trace to
the System.err stream.

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());
}

Answer:

I hope this might help you….

if you want to print the message “Data is null”, then instead of using the Build-in class “Exception”, try to use the name of your own class where you have wrote this code.
for example:
if the class name is “DemoClass” (the class where you wrote this code), then write like this:

 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());}

and if you are re-throwing, then don’t forget to mention “throws DemoClass” by the side of your function (where this code is written):

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

Answer:

In my case it was returning the wrong Exception with a null message, because I wrapped the result of the method call in an Optional variable:

It was a call to a MongoRepository database operation:

 Optional<CustomerDB> result = Optional.of(repository.findByToken(token));

The function “repository.findByToken(token)” was just returning a CustomerDB object.

I changed the code line to:

CustomerDB result = repository.findByToken(token);

And I got the right exception with the message.

Leave a Reply

Your email address will not be published. Required fields are marked *