Related
This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
What are Null Pointer Exceptions (java.lang.NullPointerException) and what causes them?
What methods/tools can be used to determine the cause so that you stop the exception from causing the program to terminate prematurely?
There are two overarching types of variables in Java:
Primitives: variables that contain data. If you want to manipulate the data in a primitive variable you can manipulate that variable directly. By convention primitive types start with a lowercase letter. For example variables of type int or char are primitives.
References: variables that contain the memory address of an Object i.e. variables that refer to an Object. If you want to manipulate the Object that a reference variable refers to you must dereference it. Dereferencing usually entails using . to access a method or field, or using [ to index an array. By convention reference types are usually denoted with a type that starts in uppercase. For example variables of type Object are references.
Consider the following code where you declare a variable of primitive type int and don't initialize it:
int x;
int y = x + x;
These two lines will crash the program because no value is specified for x and we are trying to use x's value to specify y. All primitives have to be initialized to a usable value before they are manipulated.
Now here is where things get interesting. Reference variables can be set to null which means "I am referencing nothing". You can get a null value in a reference variable if you explicitly set it that way, or a reference variable is uninitialized and the compiler does not catch it (Java will automatically set the variable to null).
If a reference variable is set to null either explicitly by you or through Java automatically, and you attempt to dereference it you get a NullPointerException.
The NullPointerException (NPE) typically occurs when you declare a variable but did not create an object and assign it to the variable before trying to use the contents of the variable. So you have a reference to something that does not actually exist.
Take the following code:
Integer num;
num = new Integer(10);
The first line declares a variable named num, but it does not actually contain a reference value yet. Since you have not yet said what to point to, Java sets it to null.
In the second line, the new keyword is used to instantiate (or create) an object of type Integer, and the reference variable num is assigned to that Integer object.
If you attempt to dereference num before creating the object you get a NullPointerException. In the most trivial cases, the compiler will catch the problem and let you know that "num may not have been initialized," but sometimes you may write code that does not directly create the object.
For instance, you may have a method as follows:
public void doSomething(SomeObject obj) {
// Do something to obj, assumes obj is not null
obj.myMethod();
}
In which case, you are not creating the object obj, but rather assuming that it was created before the doSomething() method was called. Note, it is possible to call the method like this:
doSomething(null);
In which case, obj is null, and the statement obj.myMethod() will throw a NullPointerException.
If the method is intended to do something to the passed-in object as the above method does, it is appropriate to throw the NullPointerException because it's a programmer error and the programmer will need that information for debugging purposes.
In addition to NullPointerExceptions thrown as a result of the method's logic, you can also check the method arguments for null values and throw NPEs explicitly by adding something like the following near the beginning of a method:
// Throws an NPE with a custom error message if obj is null
Objects.requireNonNull(obj, "obj must not be null");
Note that it's helpful to say in your error message clearly which object cannot be null. The advantage of validating this is that 1) you can return your own clearer error messages and 2) for the rest of the method you know that unless obj is reassigned, it is not null and can be dereferenced safely.
Alternatively, there may be cases where the purpose of the method is not solely to operate on the passed in object, and therefore a null parameter may be acceptable. In this case, you would need to check for a null parameter and behave differently. You should also explain this in the documentation. For example, doSomething() could be written as:
/**
* #param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj == null) {
// Do something
} else {
// Do something else
}
}
Finally, How to pinpoint the exception & cause using Stack Trace
What methods/tools can be used to determine the cause so that you stop
the exception from causing the program to terminate prematurely?
Sonar with find bugs can detect NPE.
Can sonar catch null pointer exceptions caused by JVM Dynamically
Now Java 14 has added a new language feature to show the root cause of NullPointerException. This language feature has been part of SAP commercial JVM since 2006.
In Java 14, the following is a sample NullPointerException Exception message:
in thread "main" java.lang.NullPointerException: Cannot invoke "java.util.List.size()" because "list" is null
List of situations that cause a NullPointerException to occur
Here are all the situations in which a NullPointerException occurs, that are directly* mentioned by the Java Language Specification:
Accessing (i.e. getting or setting) an instance field of a null reference. (static fields don't count!)
Calling an instance method of a null reference. (static methods don't count!)
throw null;
Accessing elements of a null array.
Synchronising on null - synchronized (someNullReference) { ... }
Any integer/floating point operator can throw a NullPointerException if one of its operands is a boxed null reference
An unboxing conversion throws a NullPointerException if the boxed value is null.
Calling super on a null reference throws a NullPointerException. If you are confused, this is talking about qualified superclass constructor invocations:
class Outer {
class Inner {}
}
class ChildOfInner extends Outer.Inner {
ChildOfInner(Outer o) {
o.super(); // if o is null, NPE gets thrown
}
}
Using a for (element : iterable) loop to loop through a null collection/array.
switch (foo) { ... } (whether its an expression or statement) can throw a NullPointerException when foo is null.
foo.new SomeInnerClass() throws a NullPointerException when foo is null.
Method references of the form name1::name2 or primaryExpression::name throws a NullPointerException when evaluated when name1 or primaryExpression evaluates to null.
a note from the JLS here says that, someInstance.someStaticMethod() doesn't throw an NPE, because someStaticMethod is static, but someInstance::someStaticMethod still throw an NPE!
* Note that the JLS probably also says a lot about NPEs indirectly.
NullPointerExceptions are exceptions that occur when you try to use a reference that points to no location in memory (null) as though it were referencing an object. Calling a method on a null reference or trying to access a field of a null reference will trigger a NullPointerException. These are the most common, but other ways are listed on the NullPointerException javadoc page.
Probably the quickest example code I could come up with to illustrate a NullPointerException would be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
On the first line inside main, I'm explicitly setting the Object reference obj equal to null. This means I have a reference, but it isn't pointing to any object. After that, I try to treat the reference as though it points to an object by calling a method on it. This results in a NullPointerException because there is no code to execute in the location that the reference is pointing.
(This is a technicality, but I think it bears mentioning: A reference that points to null isn't the same as a C pointer that points to an invalid memory location. A null pointer is literally not pointing anywhere, which is subtly different than pointing to a location that happens to be invalid.)
What is a NullPointerException?
A good place to start is the JavaDocs. They have this covered:
Thrown when an application attempts to use null in a case where an
object is required. These include:
Calling the instance method of a null object.
Accessing or modifying the field of a null object.
Taking the length of null as if it were an array.
Accessing or modifying the slots of null as if it were an array.
Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other
illegal uses of the null object.
It is also the case that if you attempt to use a null reference with synchronized, that will also throw this exception, per the JLS:
SynchronizedStatement:
synchronized ( Expression ) Block
Otherwise, if the value of the Expression is null, a NullPointerException is thrown.
How do I fix it?
So you have a NullPointerException. How do you fix it? Let's take a simple example which throws a NullPointerException:
public class Printer {
private String name;
public void setName(String name) {
this.name = name;
}
public void print() {
printString(name);
}
private void printString(String s) {
System.out.println(s + " (" + s.length() + ")");
}
public static void main(String[] args) {
Printer printer = new Printer();
printer.print();
}
}
Identify the null values
The first step is identifying exactly which values are causing the exception. For this, we need to do some debugging. It's important to learn to read a stacktrace. This will show you where the exception was thrown:
Exception in thread "main" java.lang.NullPointerException
at Printer.printString(Printer.java:13)
at Printer.print(Printer.java:9)
at Printer.main(Printer.java:19)
Here, we see that the exception is thrown on line 13 (in the printString method). Look at the line and check which values are null by
adding logging statements or using a debugger. We find out that s is null, and calling the length method on it throws the exception. We can see that the program stops throwing the exception when s.length() is removed from the method.
Trace where these values come from
Next check where this value comes from. By following the callers of the method, we see that s is passed in with printString(name) in the print() method, and this.name is null.
Trace where these values should be set
Where is this.name set? In the setName(String) method. With some more debugging, we can see that this method isn't called at all. If the method was called, make sure to check the order that these methods are called, and the set method isn't called after the print method.
This is enough to give us a solution: add a call to printer.setName() before calling printer.print().
Other fixes
The variable can have a default value (and setName can prevent it being set to null):
private String name = "";
Either the print or printString method can check for null, for example:
printString((name == null) ? "" : name);
Or you can design the class so that name always has a non-null value:
public class Printer {
private final String name;
public Printer(String name) {
this.name = Objects.requireNonNull(name);
}
public void print() {
printString(name);
}
private void printString(String s) {
System.out.println(s + " (" + s.length() + ")");
}
public static void main(String[] args) {
Printer printer = new Printer("123");
printer.print();
}
}
See also:
Avoiding “!= null” statements in Java?
I still can't find the problem
If you tried to debug the problem and still don't have a solution, you can post a question for more help, but make sure to include what you've tried so far. At a minimum, include the stacktrace in the question, and mark the important line numbers in the code. Also, try simplifying the code first (see SSCCE).
Question: What causes a NullPointerException (NPE)?
As you should know, Java types are divided into primitive types (boolean, int, etc.) and reference types. Reference types in Java allow you to use the special value null which is the Java way of saying "no object".
A NullPointerException is thrown at runtime whenever your program attempts to use a null as if it was a real reference. For example, if you write this:
public class Test {
public static void main(String[] args) {
String foo = null;
int length = foo.length(); // HERE
}
}
the statement labeled "HERE" is going to attempt to run the length() method on a null reference, and this will throw a NullPointerException.
There are many ways that you could use a null value that will result in a NullPointerException. In fact, the only things that you can do with a null without causing an NPE are:
assign it to a reference variable or read it from a reference variable,
assign it to an array element or read it from an array element (provided that array reference itself is non-null!),
pass it as a parameter or return it as a result, or
test it using the == or != operators, or instanceof.
Question: How do I read the NPE stacktrace?
Suppose that I compile and run the program above:
$ javac Test.java
$ java Test
Exception in thread "main" java.lang.NullPointerException
at Test.main(Test.java:4)
$
First observation: the compilation succeeds! The problem in the program is NOT a compilation error. It is a runtime error. (Some IDEs may warn your program will always throw an exception ... but the standard javac compiler doesn't.)
Second observation: when I run the program, it outputs two lines of "gobbledy-gook". WRONG!! That's not gobbledy-gook. It is a stacktrace ... and it provides vital information that will help you track down the error in your code if you take the time to read it carefully.
So let's look at what it says:
Exception in thread "main" java.lang.NullPointerException
The first line of the stack trace tells you a number of things:
It tells you the name of the Java thread in which the exception was thrown. For a simple program with one thread (like this one), it will be "main". Let's move on ...
It tells you the full name of the exception that was thrown; i.e. java.lang.NullPointerException.
If the exception has an associated error message, that will be output after the exception name. NullPointerException is unusual in this respect, because it rarely has an error message.
The second line is the most important one in diagnosing an NPE.
at Test.main(Test.java:4)
This tells us a number of things:
"at Test.main" says that we were in the main method of the Test class.
"Test.java:4" gives the source filename of the class, AND it tells us that the statement where this occurred is in line 4 of the file.
If you count the lines in the file above, line 4 is the one that I labeled with the "HERE" comment.
Note that in a more complicated example, there will be lots of lines in the NPE stack trace. But you can be sure that the second line (the first "at" line) will tell you where the NPE was thrown1.
In short, the stack trace will tell us unambiguously which statement of the program has thrown the NPE.
See also: What is a stack trace, and how can I use it to debug my application errors?
1 - Not quite true. There are things called nested exceptions...
Question: How do I track down the cause of the NPE exception in my code?
This is the hard part. The short answer is to apply logical inference to the evidence provided by the stack trace, the source code, and the relevant API documentation.
Let's illustrate with the simple example (above) first. We start by looking at the line that the stack trace has told us is where the NPE happened:
int length = foo.length(); // HERE
How can that throw an NPE?
In fact, there is only one way: it can only happen if foo has the value null. We then try to run the length() method on null and... BANG!
But (I hear you say) what if the NPE was thrown inside the length() method call?
Well, if that happened, the stack trace would look different. The first "at" line would say that the exception was thrown in some line in the java.lang.String class and line 4 of Test.java would be the second "at" line.
So where did that null come from? In this case, it is obvious, and it is obvious what we need to do to fix it. (Assign a non-null value to foo.)
OK, so let's try a slightly more tricky example. This will require some logical deduction.
public class Test {
private static String[] foo = new String[2];
private static int test(String[] bar, int pos) {
return bar[pos].length();
}
public static void main(String[] args) {
int length = test(foo, 1);
}
}
$ javac Test.java
$ java Test
Exception in thread "main" java.lang.NullPointerException
at Test.test(Test.java:6)
at Test.main(Test.java:10)
$
So now we have two "at" lines. The first one is for this line:
return args[pos].length();
and the second one is for this line:
int length = test(foo, 1);
Looking at the first line, how could that throw an NPE? There are two ways:
If the value of bar is null then bar[pos] will throw an NPE.
If the value of bar[pos] is null then calling length() on it will throw an NPE.
Next, we need to figure out which of those scenarios explains what is actually happening. We will start by exploring the first one:
Where does bar come from? It is a parameter to the test method call, and if we look at how test was called, we can see that it comes from the foo static variable. In addition, we can see clearly that we initialized foo to a non-null value. That is sufficient to tentatively dismiss this explanation. (In theory, something else could change foo to null ... but that is not happening here.)
So what about our second scenario? Well, we can see that pos is 1, so that means that foo[1] must be null. Is this possible?
Indeed it is! And that is the problem. When we initialize like this:
private static String[] foo = new String[2];
we allocate a String[] with two elements that are initialized to null. After that, we have not changed the contents of foo ... so foo[1] will still be null.
What about on Android?
On Android, tracking down the immediate cause of an NPE is a bit simpler. The exception message will typically tell you the (compile time) type of the null reference you are using and the method you were attempting to call when the NPE was thrown. This simplifies the process of pinpointing the immediate cause.
But on the flipside, Android has some common platform-specific causes for NPEs. A very common is when getViewById unexpectedly returns a null. My advice would be to search for Q&As about the cause of the unexpected null return value.
It's like you are trying to access an object which is null. Consider below example:
TypeA objA;
At this time you have just declared this object but not initialized or instantiated. And whenever you try to access any property or method in it, it will throw NullPointerException which makes sense.
See this below example as well:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
A null pointer exception is thrown when an application attempts to use null in a case where an object is required. These include:
Calling the instance method of a null object.
Accessing or modifying the field of a null object.
Taking the length of null as if it were an array.
Accessing or modifying the slots of null as if it were an array.
Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other illegal uses of the null object.
Reference: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html
A null pointer is one that points to nowhere. When you dereference a pointer p, you say "give me the data at the location stored in "p". When p is a null pointer, the location stored in p is nowhere, you're saying "give me the data at the location 'nowhere'". Obviously, it can't do this, so it throws a null pointer exception.
In general, it's because something hasn't been initialized properly.
A lot of explanations are already present to explain how it happens and how to fix it, but you should also follow best practices to avoid NullPointerExceptions at all.
See also:
A good list of best practices
I would add, very important, make a good use of the final modifier.
Using the "final" modifier whenever applicable in Java
Summary:
Use the final modifier to enforce good initialization.
Avoid returning null in methods, for example returning empty collections when applicable.
Use annotations #NotNull and #Nullable
Fail fast and use asserts to avoid propagation of null objects through the whole application when they shouldn't be null.
Use equals with a known object first: if("knownObject".equals(unknownObject)
Prefer valueOf() over toString().
Use null safe StringUtils methods StringUtils.isEmpty(null).
Use Java 8 Optional as return value in methods, Optional class provide a solution for representing optional values instead of null references.
A null pointer exception is an indicator that you are using an object without initializing it.
For example, below is a student class which will use it in our code.
public class Student {
private int id;
public int getId() {
return this.id;
}
public setId(int newId) {
this.id = newId;
}
}
The below code gives you a null pointer exception.
public class School {
Student student;
public School() {
try {
student.getId();
}
catch(Exception e) {
System.out.println("Null pointer exception");
}
}
}
Because you are using student, but you forgot to initialize it like in the
correct code shown below:
public class School {
Student student;
public School() {
try {
student = new Student();
student.setId(12);
student.getId();
}
catch(Exception e) {
System.out.println("Null pointer exception");
}
}
}
In Java, everything (excluding primitive types) is in the form of a class.
If you want to use any object then you have two phases:
Declare
Initialization
Example:
Declaration: Object object;
Initialization: object = new Object();
Same for the array concept:
Declaration: Item item[] = new Item[5];
Initialization: item[0] = new Item();
If you are not giving the initialization section then the NullPointerException arise.
In Java all the variables you declare are actually "references" to the objects (or primitives) and not the objects themselves.
When you attempt to execute one object method, the reference asks the living object to execute that method. But if the reference is referencing NULL (nothing, zero, void, nada) then there is no way the method gets executed. Then the runtime let you know this by throwing a NullPointerException.
Your reference is "pointing" to null, thus "Null -> Pointer".
The object lives in the VM memory space and the only way to access it is using this references. Take this example:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
And on another place in your code:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
This an important thing to know - when there are no more references to an object (in the example above when reference and otherReference both point to null) then the object is "unreachable". There is no way we can work with it, so this object is ready to be garbage collected, and at some point, the VM will free the memory used by this object and will allocate another.
Another occurrence of a NullPointerException occurs when one declares an object array, then immediately tries to dereference elements inside of it.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
This particular NPE can be avoided if the comparison order is reversed; namely, use .equals on a guaranteed non-null object.
All elements inside of an array are initialized to their common initial value; for any type of object array, that means that all elements are null.
You must initialize the elements in the array before accessing or dereferencing them.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
I want to make a method that gives a string (input in method) the value null. This is for my database, so that there are no 'open' values.
It needs to be something like this:
public string NulValue (string value)
{
value = null; //the string-value needs to get the value null here
return value; //returning the value
}
But this is not giving the string the value null. I think the solution is very easy, but I don't get it to work. I use WPF.
Here is where I want to use the method:
string checkcomment = TextBxComment.Text;
if (checkcomment == "")
{
NulValue(checkcomment);
}
You can not make a string anything. While strings are reference types, they are on that is designed to work like Value Type for many purposes. Do not try to learn class semantics with string. You can however set the reference to null, wich works similar to setting a value type to anything in a function.
By default functions use "call by value", wich means a copy of the Primitive Type or Reference variable is made. And you then work with that copy. In order to force a function to use call by reference (in wich the actually variable is re-used and can be modified), the ref and out keywords are used for that.
However teh whole operation makes little sense. As far as you example code shows, you want to set the reference variable to null. At wich point
myValue = null;
will always be easier to write and read then
NullValue(ref myValue);
But of course there might be some logic you have not shown us.
Properties can not be used as ref values. So if you use properties, you have to write somewhat more code.:
var temp = Instance.MyValue;
NullValue(ref temp);
Instance.MyValue = temp;
With a Database, this might be about mapping the .NET Type/Value Null to the Databases Type/value Null. Wich can be very different things.
It's quite annoying to test all my strings for null before I can safely apply methods like ToUpper(), StartWith() etc...
If the default value of string were the empty string, I would not have to test, and I would feel it to be more consistent with the other value types like int or double for example.
Additionally Nullable<String> would make sense.
So why did the designers of C# choose to use null as the default value of strings?
Note: This relates to this question, but is more focused on the why instead of what to do with it.
Why is the default value of the string type null instead of an empty
string?
Because string is a reference type and the default value for all reference types is null.
It's quite annoying to test all my strings for null before I can
safely apply methods like ToUpper(), StartWith() etc...
That is consistent with the behaviour of reference types. Before invoking their instance members, one should put a check in place for a null reference.
If the default value of string were the empty string, I would not have
to test, and I would feel it to be more consistent with the other
value types like int or double for example.
Assigning the default value to a specific reference type other than null would make it inconsistent.
Additionally Nullable<String> would make sense.
Nullable<T> works with the value types. Of note is the fact that Nullable was not introduced on the original .NET platform so there would have been a lot of broken code had they changed that rule.(Courtesy #jcolebrand)
Habib is right -- because string is a reference type.
But more importantly, you don't have to check for null each time you use it. You probably should throw a ArgumentNullException if someone passes your function a null reference, though.
Here's the thing -- the framework would throw a NullReferenceException for you anyway if you tried to call .ToUpper() on a string. Remember that this case still can happen even if you test your arguments for null since any property or method on the objects passed to your function as parameters may evaluate to null.
That being said, checking for empty strings or nulls is a common thing to do, so they provide String.IsNullOrEmpty() and String.IsNullOrWhiteSpace() for just this purpose.
You could write an extension method (for what it's worth):
public static string EmptyNull(this string str)
{
return str ?? "";
}
Now this works safely:
string str = null;
string upper = str.EmptyNull().ToUpper();
You could also use the following, as of C# 6.0
string myString = null;
string result = myString?.ToUpper();
The string result will be null.
Empty strings and nulls are fundamentally different. A null is an absence of a value and an empty string is a value that is empty.
The programming language making assumptions about the "value" of a variable, in this case an empty string, will be as good as initiazing the string with any other value that will not cause a null reference problem.
Also, if you pass the handle to that string variable to other parts of the application, then that code will have no ways of validating whether you have intentionally passed a blank value or you have forgotten to populate the value of that variable.
Another occasion where this would be a problem is when the string is a return value from some function. Since string is a reference type and can technically have a value as null and empty both, therefore the function can also technically return a null or empty (there is nothing to stop it from doing so). Now, since there are 2 notions of the "absence of a value", i.e an empty string and a null, all the code that consumes this function will have to do 2 checks. One for empty and the other for null.
In short, its always good to have only 1 representation for a single state. For a broader discussion on empty and nulls, see the links below.
https://softwareengineering.stackexchange.com/questions/32578/sql-empty-string-vs-null-value
NULL vs Empty when dealing with user input
Why the designers of C# chose to use null as the default value of
strings?
Because strings are reference types, reference types are default value is null. Variables of reference types store references to the actual data.
Let's use default keyword for this case;
string str = default(string);
str is a string, so it is a reference type, so default value is null.
int str = (default)(int);
str is an int, so it is a value type, so default value is zero.
The fundamental reason/problem is that the designers of the CLS specification (which defines how languages interact with .net) did not define a means by which class members could specify that they must be called directly, rather than via callvirt, without the caller performing a null-reference check; nor did it provide a meany of defining structures which would not be subject to "normal" boxing.
Had the CLS specification defined such a means, then it would be possible for .net to consistently follow the lead established by the Common Object Model (COM), under which a null string reference was considered semantically equivalent to an empty string, and for other user-defined immutable class types which are supposed to have value semantics to likewise define default values. Essentially, what would happen would be for each member of String, e.g. Length to be written as something like [InvokableOnNull()] int String Length { get { if (this==null) return 0; else return _Length;} }. This approach would have offered very nice semantics for things which should behave like values, but because of implementation issues need to be stored on the heap. The biggest difficulty with this approach is that the semantics of conversion between such types and Object could get a little murky.
An alternative approach would have been to allow the definition of special structure types which did not inherit from Object but instead had custom boxing and unboxing operations (which would convert to/from some other class type). Under such an approach, there would be a class type NullableString which behaves as string does now, and a custom-boxed struct type String, which would hold a single private field Value of type String. Attempting to convert a String to NullableString or Object would return Value if non-null, or String.Empty if null. Attempting to cast to String, a non-null reference to a NullableString instance would store the reference in Value (perhaps storing null if the length was zero); casting any other reference would throw an exception.
Even though strings have to be stored on the heap, there is conceptually no reason why they shouldn't behave like value types that have a non-null default value. Having them be stored as a "normal" structure which held a reference would have been efficient for code that used them as type "string", but would have added an extra layer of indirection and inefficiency when casting to "object". While I don't foresee .net adding either of the above features at this late date, perhaps designers of future frameworks might consider including them.
Because a string variable is a reference, not an instance.
Initializing it to Empty by default would have been possible but it would have introduced a lot of inconsistencies all over the board.
If the default value of string were the empty string, I would not have to test
Wrong! Changing the default value doesn't change the fact that it's a reference type and someone can still explicitly set the reference to be null.
Additionally Nullable<String> would make sense.
True point. It would make more sense to not allow null for any reference types, instead requiring Nullable<TheRefType> for that feature.
So why did the designers of C# choose to use null as the default value of strings?
Consistency with other reference types. Now, why allow null in reference types at all? Probably so that it feels like C, even though this is a questionable design decision in a language that also provides Nullable.
Perhaps if you'd use ?? operator when assigning your string variable, it might help you.
string str = SomeMethodThatReturnsaString() ?? "";
// if SomeMethodThatReturnsaString() returns a null value, "" is assigned to str.
A String is an immutable object which means when given a value, the old value doesn't get wiped out of memory, but remains in the old location, and the new value is put in a new location. So if the default value of String a was String.Empty, it would waste the String.Empty block in memory when it was given its first value.
Although it seems minuscule, it could turn into a problem when initializing a large array of strings with default values of String.Empty. Of course, you could always use the mutable StringBuilder class if this was going to be a problem.
Since string is a reference type and the default value for reference type is null.
Since you mentioned ToUpper(), and this usage is how I found this thread, I will share this shortcut (string ?? "").ToUpper():
private string _city;
public string City
{
get
{
return (this._city ?? "").ToUpper();
}
set
{
this._city = value;
}
}
Seems better than:
if(null != this._city)
{ this._city = this._city.ToUpper(); }
Maybe the string keyword confused you, as it looks exactly like any other value type declaration, but it is actually an alias to System.String as explained in this question.
Also the dark blue color in Visual Studio and the lowercase first letter may mislead into thinking it is a struct.
Nullable types did not come in until 2.0.
If nullable types had been made in the beginning of the language then string would have been non-nullable and string? would have been nullable. But they could not do this du to backward compatibility.
A lot of people talk about ref-type or not ref type, but string is an out of the ordinary class and solutions would have been found to make it possible.
This is valid C# code
var bob = "abc" + null + null + null + "123"; // abc123
This is not valid C# code
var wtf = null.ToString(); // compiler error
Why is the first statement valid?
The reason for first one working:
From MSDN:
In string concatenation operations,the C# compiler treats a null string the same as an empty string, but it does not convert the value of the original null string.
More information on the + binary operator:
The binary + operator performs string concatenation when one or both operands are of type string.
If an operand of string concatenation is null, an empty string is substituted. Otherwise, any non-string argument is converted to its string representation by invoking the virtual ToString method inherited from type object.
If ToString returns null, an empty string is substituted.
The reason of the error in second is:
null (C# Reference) - The null keyword is a literal that represents a null reference, one that does not refer to any object. null is the default value of reference-type variables.
Because the + operator in C# internally translates to String.Concat, which is a static method. And this method happens to treat null like an empty string. If you look at the source of String.Concat in Reflector, you'll see it:
// while looping through the parameters
strArray[i] = (str == null) ? Empty : str;
// then concatenate that string array
(MSDN mentions it, too: http://msdn.microsoft.com/en-us/library/k9c94ey1.aspx)
On the other hand, ToString() is an instance method, which you cannot call on null (what type should be used for null?).
The first sample will be translated into:
var bob = String.Concat("abc123", null, null, null, "abs123");
The Concat method checks input and translate null as an empty string
The second sample will be translated into:
var wtf = ((object)null).ToString();
So a null reference exception will be generated here
The first part of your code is just treated like that in String.Concat,
which is what the C# compiler calls when you add strings. "abc" + null gets translated to String.Concat("abc", null),
and internally, that method replaces null with String.Empty. So, that's why your first part of code does not throw any exception. it is just like
var bob = "abc" + string.Empty + string.Empty + string.Empty + "123"; //abc123
And in 2nd part of your code throws exception because 'null' is not an object, the null keyword is a literal that represents a null reference, one that does not refer to any object. null is the default value of reference-type variables.
And 'ToString()' is a method that can be called by an instance of an object but not any literal.
In the COM framework which preceded .net, it was necessary for any routine which received a string to free it when it was done with it. Because it was very common for empty strings to be passed into and out of routines, and because attempting to "free" a null pointer was defined as a legitimate do-nothing operation, Microsoft decided to have a null string pointer represent an empty string.
To allow for some compatibility with COM, many routines in .net will interpret a null object as a legal representation as an empty string. With a couple of slight changes .net and its languages (most notably allowing instance members to indicate "do not invoke as virtual"), Microsoft could have made null objects of declared type String behave even more like empty strings. If Microsoft had done that, it would have also had to make Nullable<T> work somewhat differently (so as to allow Nullable<String>--something they should IMHO have done anyway) and/or define a NullableString type which would be mostly interchangeable with String, but which would not regard a null as a valid empty string.
As it is, there are some contexts in which a null will be regarded as a legitimate empty string and others in which it won't. Not a terribly helpful situation, but one which programmers should be aware of. In general, expressions of the form stringValue.someMember will fail if stringValue is null, but most framework methods and operators which accept strings as parameters will regard null as an empty string.
'+' is an infix operator. Like any operator it is really calling a method. You could imagine a the non-infix version "wow".Plus(null) == "wow"
The implementer has decided on something like this...
class String
{
...
String Plus(ending)
{
if(ending == null) return this;
...
}
}
So.. your example becomes
var bob = "abc".Plus(null).Plus(null).Plus(null).Plus("123"); // abc123
which is the same as
var bob = "abc".Plus("123"); // abc123
At no point does null become a string. So null.ToString() is no different that null.VoteMyAnswer(). ;)
I guess because it's a literal which doesn't refer to any object. ToString() needs an object.
Adding null to a string is simply ignored. null (in your second example) isn't an instance of any object, so it doesn't even have a ToString() method. It's just a literal.
Someone said in this discussion thread that you can't make a string out of nothing.
(which is a nice phrase as I think). But yes - you can :-), as the following example shows:
var x = null + (string)null;
var wtf = x.ToString();
works fine and does not throw an exception at all. The only difference is that you need to cast one of the nulls into a string - if you remove the (string) cast, then the example still compiles, but throws a run-time exception: "Operator '+' is ambiguous on operands of type '<null>' and '<null>'".
N.B. In the code example above, the value of x is not null as you might expect, it is actually an empty string after you have casted one of the operands into a string.
Slightly different is var a = ((string)null).ToString(); - which compiles but will throw a NullReferenceException. In this case the exception is thrown because the . operator isn't allowed on null values. Using ?. would work here (but ToString isn't executed in this case). The compiler will correctly "create" the variable a as a string.
Another interesting fact is that in C# / .NET the way null is treated is not always the same if you regard different data types. For example:
int? x = 1; // string x = "1";
x = x + null + null;
Console.WriteLine((x==null) ? "<null>" : x.ToString());
Regard the 1st line of the code snippet: If x is a nullable integer variable (i.e. int?) containing value 1, then you're getting the result <null> back. If it is a string (as shown in the comment) with value "1", then you're getting "1" back rather than <null>.
N.B. Also interesting: If you're using var x = 1; for the first line, then you're getting a runtime error. Why? Because the assignment will turn the variable x into the datatype int, which is not nullable. The compiler does not assume int? here, and hence fails in the 2nd line where null is added.
Because there is no difference between string.Empty and null when you concat strings.
You can pass null into string.Format as well. But you are trying to call a method on null, which would always result in a NullReferenceException and therefore generates a compiler error.
If for some reason you really want to do it, you could write an extension method, that checks for null and then returns string.Empty. But an extension like that should only be used when absolutly necessary (in my opinion).
As general: It may or may not valid accepting null as a parameter depending on specification, but it is always invalid to call a method on null.
That's and other topic why the + operator's operands can be null in case of strings. This is kinda VB thing (sorry guys) to make programmers life easier, or supposing the programmer can not deal with nulls. I completely disagree this specification. 'unknown' + 'anything' should be still 'unknown'...
As a programmer I would have expected this to throw an exception. Is there a reason why it treats null as ""?
string s = "hello";
string t = null;
Console.WriteLine(s + t);
Output:
hello
Just to emphasise my question, do you know why the decision to turn null into String.Empty was made? I was expecting some string to be added but there was a problem further back where it wasn't retrieving it properly and it came back with null. The problem went unnoticed!
Here's a pseudocode of why I think it is bad (and why I was shocked to discover no error):
You can assume I overloaded ToString to give the name of the person or details about them.
Person p = PersonDatabase.GetForName("Jimmy Gibbs");
Console.WriteLine("Name is: " + p.ToString());
Throws an exception because p is null
String p = PersonDatabase.GetForName("Jimmy Gibbs").Name;
Console.WriteLine("Name is: " + p);
Doesn't throw an exception, even though p is null (it treats it as "").
(If you want to be picky and say I won't be able to get Name as GetforName will be null, think of it as this:)
String p = PersonDatabase.GetNameFromID(1234); // Returns a string or null if not found
Console.WriteLine("Name is: " + p);
(If you use this value in a list or array you'll end up with a blank entry which is what broke for me, it was creating javascript and trying to get element by ID of "")
From the C# Language Specification:
7.8.4 Addition operator
String concatenation:
string operator +(string x, string y);
string operator +(string x, object y);
string operator +(object x, string y);
These overloads of the binary +
operator perform string concatenation.
If an operand of string concatenation
is null, an empty string is
substituted. Otherwise, any non-string
argument is converted to its string
representation by invoking the virtual
ToString method inherited from type
object. If ToString returns null, an
empty string is substituted.
The + operator is emitted as string.Concat in the resulting IL.
s + t = string.Concat(s, t)
and when looking at the implementation it checks whether arguments are null and returns string.Empty:
Disassembled with reflector:
[SecuritySafeCritical]
public static string Concat(string str0, string str1)
{
if (IsNullOrEmpty(str0))
{
if (IsNullOrEmpty(str1))
{
return Empty;
}
return str1;
}
if (IsNullOrEmpty(str1))
{
return str0;
}
int length = str0.Length;
string dest = FastAllocateString(length + str1.Length);
FillStringChecked(dest, 0, str0);
FillStringChecked(dest, length, str1);
return dest;
}
When thinking about design decision that was made, we should look not only at plus operator for Strings but also at related classes and methods, e.g. String.Concat(String, String) and StringBuilder.Append(String). Those classes are part of Base Class Library which in widely used in other languegges (e.g. Visual Basic and F#).
From language and platform design perspective, all those methods should behave in a consistent faction (i.e. treat null in the same way). I see three possible options:
Throw exception
This is a "safe" solution since it's not clear what to do with null. As a tradeoff, it would require a more defensive style of programming and more verbose code.
Use some representation for null e.g. <null>, null or [null] (Java-style)
This is an outcome that you expected. It is not clear why this should happen and how exactly null should be represented.
Treat null in the same fashion as empty string (.NET-style)
The idea behind it is that textual representation of null (i.e. an object that is missing) is an empty string. In that case, a programmer can exploit this behavior and write shorter code. On the other hand, it can hide bugs.
Some decision had to be made and I think that there's no obvious choice. Expected behavior in C# and other .NET languages is clearly documented and it's consistent across all the methods that deal with concatenation.
In string concatenation operations, the C# compiler treats a null string the same as an empty string, but it does not convert the value of the original null string. Additional information here http://msdn.microsoft.com/en-us/library/aa691375(VS.71).aspx
If I have an Orange and add another Orange, I now have two oranges.
If I have an Orange and add NOTHING, I still have an orange.
To me adding NULL to a string and getting the original string seems perfectly intuitive and semantic. NullReferenceExceptions should be reserved for when accessing Properties or instance methods on instances that don't exist, eg.
string myString = null;
string lowerCaseString = myString.ToLower();
Would understandably throw a NullReferenceException because I'm trying to access the ToLower() instance method on a reference that doesn't exist hence Null Reference Exception (ie. there's a thing on the Stack, but nothing on the Heap).
Having NULL string concat operations throw exceptions would mean tonnes of extra defensive NULL code checks when dealing with strings, which are annoying. Sorry, but I happen to agree with how C#.NET handles this. Doesn't Java do the same?
If you want to check if a string contains a value then use String.IsNullOrEmpty(myString); or String.IsNullOrWhitespace(myString); (only in .NET 4.0)
User defined operators are just static methods and of course can accept null parameters. This is for example really useful for delegates.
So string accepting null is no technical but a design decision. And it's probably sometimes useful to treat null as "" since a lot of user code treats them the same.
Actually this is how strings are represented.... nothing wrong there.
null is used as a termination character.
For example:
string a: "blahblah[null]"
So whatever reads the string knows to stop at null.
so then when you create a string like this:
string b: "[null]"
it is perfectly valid.
Now, there are no characters before null. so when your program starts reading the string it encounters null (perfectly valid) and stops.... thus... empty string!!