Question

If the compiler is going to complain that a String object is not initialized then is it appropriate to check in my method whether the String object is null or not?

Is there a place that the compiler will not check that for me?

Answer 1

Two issues here – the one in the title and the one you seem to be asking.

Initialisation

The compiler is complaining about “initialisation” not whether or not it is null.

Initialisation is simply that you have given it a value – either by setting it to point to a specific String object or by explicitely setting it to null.

Prior to initialisation the value of the variable is unknown… roughly speaking it is whatever value just happens to have been left in that memory address by the last thing that used it.

However you don’t need to worry about checking for initialisation at run time – the compiler won’t let you get to the point where it is an issue.

Null Reference Checks

Your headline question of “do I have to check whether a String object is null?” however is a slightly different issue and that you do have to consider at run time.

There are three ways to handle null references.

1. Check that the references are not null in your logic (i.e. in an if statement)
2. Put the check in an assertion
3. Put the code in a try/catch block with an explicit catch for java.lang.NullPointerException
4. Ignore the issue completely

The last option simply means that if a null is used then the exception will run all the way back to the entry point of the thread into your code and terminate the thread.

It is because of this it is always wise to put a global catch around each thread entry point for your code – one which as a minimum reports that an unhandled exception occurred with plenty of information to help you work out what happened (probably before terminating the application as it is in an unplanned & unexpected state).

Which of the above options you do really depends on the likelihood of there being a null pointer at that point. If the reference was created and managed in the current class and you know that it is “impossible” for it to be null, then option 4 is valid.

Conversely if you are creating generic code that other developers (possibly outside of your control) might call and particularly where the null could have long-term detrimental effects to your object (e.g. you may use it to set something that will only break your code much later) then option 1 is worthwhile.

Option 2 is useful if you want to be able to turn it off after testing and also to make it clear in the code that the test isn’t part of the algorithm, just a safety measure

Option 3 is rare, but can be used if you have a lot of variables being passed in with a slim chance of them being an issue, but if they are then the problem will manifest during the call.