Every once in awhile, you come across this exception:
System.NullReferenceException – “Object reference not set to an
instance of an object.” You see people asking about this
everywhere; about why are they getting this error. Below are a
few common causes for this.
Note, regardless of the scenario, the cause is always the same in .Net:
You are trying to use a reference variable who's value is
Nothing/null. When the value is Nothing/null for the reference
variable, that means it is not actually holding a reference to an
instance of any object that exists on the heap. You either never
assigned something to the variable, never created an instance of the
value assigned to the variable, or you set the variable equal to
Nothing/null manually, or you called a function that set the variable
to Nothing/null for you.
1. In VB.Net, you are trying to access a string
that has not been initialized. In C#, this isn’t possible.
You can’t even compile code like the following in C#
However, in VB.Net, you can compile the equivalent, and that lead right down a road to the mentioned exception.
Remember, a string is a reference type (a character array) that has
to have a value. You don’t have to use the “new” keyword, but by
default the value is Nothing/null. You would have to at least
initialize to a = String.Empty, or to some other actual value, before
it will compile in C#, or run without exception in VB.Net
To fix this above problem in VB.Net, set [a = “something”] before you attempt to do anything with it.
2. You never created a new instance of an
object. Again, this is code that C# will not compile, but VB.Net
will, and throw a runtime error. Same as a string, any reference
type must be initialized. Strings and some other CTS
types have a misconception of being value types, like Integers, and
they are not.
Here is the VB equivalent, that will compile, but throw the mentioned exception.
To fix the problem, you need to say [Dim b As New ArrayList] in the above code.
3. You created the object, but killed it too soon. Here is a simple example of that.
A more complex example would be that you disposed of a class that
maybe you use to access the database. This killed the connection
and command objects. But then, somewhere else, you tried to call
a method of that class that used those objects that no longer
exists. Again, same exception gets thrown, but coming from
withing the instantiated class itself.
The GetOrders function inside of Customers requires an instance of a
connection, but you disposed of the required objects required to access
the database back up in LoadData() when you called a.Dispose().
Be careful when you clean up your instances, that you are not using
them again somewhere. This is most common in classes where you
are using class-wide instantiated objects. If you create and drop
your objects within each method, this isn’t going to be a problem, and
you are actually following a better guideline by creating at the last
necessary moment, and destroying at the first possible moment, not to
mention avoiding possible exceptions like InvalidReferenceException.