Thread: string handling

can someone please make me understand when to initialise a string 'null' and when not..??

Originally Posted by shilpy

can someone please make me understand when to initialise a string 'null' and when not..??

When you need the String variable to be null you should set its value to null. If you need it to be a String you should set it to a String.

But more seriously, we can not answer your question because it depends on what you want and what you need, and the answer changes depending on the rest of your program.

1. String a = "";
2. String b = null;

Line 1 create a String object and assigns it the reference 'a'.
Line 2 only creates a reference( 'b' ) to a String object. It will need to be assigned a String object before it can be used. If you try to use before-hand, you'll get a null pointer exception.

Originally Posted by kaufenpreis

1. String a = "";
2. String b = null;

Line 1 create a String object and assigns it the reference 'a'.
Line 2 only creates a reference( 'b' ) to a String object. It will need to be assigned a String object before it can be used. If you try to use before-hand, you'll get a null pointer exception.

NULL POINTER EXCEPTION ??? MEANS

--- Update ---

i still don't get it..!!

Originally Posted by Norm

null is a value that object reference variables can have. Since a String class instance is an object, any variable that is a reference to a String can have a null value.

The compiler wants local (defined inside a method) variables to be initialized to a value. Class level variables are given default values which is null for object reference variables.

It's best to always initialize variables.

Maybe not _always_.

Originally Posted by Norm

If you always do it, then the chances of not doing it when it is needed is removed. It removes one more decision to make when writing code.

There isn't a hard-and-fast rule, but arbitrarily assigning defaults to those properties/fields that are already set to defaults for you makes larger code.

If you use an IDE it will warn you of possible null dereferences or using an unassigned variable.

For objects this is silly anyway, as you are probably going to assign it to null (unless you are statically initializing it to something reasonable, which is a different case) in which case, nothing changes at runtime with respect to accidentally using it.

So, this leaves us with non-object fields. Which should either be initialized in a constructor, statically if they are defaults or final (but then they are defaults or constants anyway, so initialization makes sense) or via lazy initialization in a getter (or an explicit setter, of that makes sense.)

The point I'm making is that this is contextual, and it is up to the big throbbing brain this sits between the computer and the keyboard to make the right choices. The code should reflect the intent of the coder, and non-meaningful defaults do not reflect how those fields are to be used.

Finally, default initializing can lead to costly and obscure runtime bugs that I'd rather find at compile time, or explicitly exercise with unit tests. That is, the assertion that initializing fields lowers instances of defects is not true; you just introduce a different set of bugs.

I'll point out this is exactly the sort of thing that does not happen with C# properties. You can't just define a property and abuse it like this; you have to declare the property and force yourself to refer to it only in this manner.

My advice is to be disciplined in this case, and treat your fields as fields. Even if the language allows you to be lazy.