While we can easily just do a check to ensure we are not trying to access a null reference, this is not always a suitable solution. Many times, in Unity programming, our problem may derive from the fact that the reference should not be null. In some situations, simply ignoring null references can break our code.

For example, it might be a reference to our input controller. It is great that the game does not crash due to the null reference exception, but we need to figure out why there is no input controller, and fix that problem. Without it, we have a game that may not crash, but can not take input, either.

Below, I will list possible reasons and solutions, as I come across them in other questions.

Are you trying to access a "manager" class?

If your trying to access a class that acts as a "manager" (that is, a class that should only ever have one instance running at a time), you might be better off using the Singleton approach. A Singleton class can ideally be accessed from anywhere, directly, by keeping a public static reference to itself. In this way, a Singleton can contain a reference to the active instance, which would be accessible without the trouble of setting up the actual reference every time.

Are you referencing the instance of your object?

It is common to simply mark a reference as public, so we can set the reference to the instance via the inspector. Always check that you have set the reference to an instance, via the inspector, as it is not uncommon to miss this step.

Are you instantiating your instance?

If we are setting up our object in code, it is important to ensure that we instantiate the object. This can be carried out using the new keyword and the constructor methods. For example, consider the following:

private GameObject gameObject;

We have created a reference to a GameObject, but it does not point to anything. Accessing this reference as is will result in a null reference exception. Before we reference our GameObject instance, we may call a default constructor method as follows:

gameObject = new GameObject();

The Unity tutorial on classes explains the practice of creating and using constructors.

Are you using the GetComponent<t>() method with the assumption that the component exists?

First, ensure that we always call GetComponent<t>() before we call methods from the component instance.

For reasons not worth going in to, we may assume our local game object contains a particular component, and try to access it with GetComponent<t>(). If the local game object does not contain that particular component, we will return a null value.

You could easily check if the returning value is null, prior to accessing it. However, if your game object should have the required component, it may be better to ensure that it at least has a default version of that component. We can tag a MonoBehaviour as \[RequireComponent(typeof(t))\] to ensure we always have that type of component.

Here is an example of a MonoBehaviour for a game object that should always contain a Rigidbody. If the script is added to a game object that does not contain a Rigidbody, a default Rigidbody will be created.

[RequireComponent(typeof(Rigidbody))]
public class AlwaysHasRigidbody : MonoBehaviour
{
    Rigidbody myRigidbody;
    

    void Start()
    {
        myRigidbody = GetComponent<Rigidbody>();
    }
}

Have you tried to re-build your project?

There are some cases where Unity may cause problems by trying to reference a cached version of a game object. In line with the age old "turn it off and on again" solution, try deleting your Library folder, and re-open Unity. Unity will be forced to re-build your project. This can solve some very peculiar instances of this problem, and should point to issues that would not come up in a final build.