NullReferenceException in StartCoroutine

I am getting reports in our crash tracking system, that users seem to be getting a NullReferenceException in StartCoroutine.

The code roughly looks like this:

Code (CSharp):

1. void Start()
2. {
3.     DownloadSomething("url", Callback);
4. }
5.  
6. void Callback()
7. {
8.     StartCoroutine(OnCompletion());
9. }
10.  
11. IEnumerator OnCompletion()
12. {
13.     // ... code here
14. }

Essentially the steps are:

1. Starting some long running operation, passing a callback delegate into it.
2. When the operation completes, the delegate gets called.
3. The completion delegate starts a coroutine that should do something (e.g: load a level).

During my testing, i could not reproduce this exception. What can cause StartCoroutine to throw this exception? (Note that the stack trace i am getting is in StartCoroutine itself, not in my method).

 

use

Code (csharp):

1. StartCoroutine("OnCompletion");

 

Can you elaborate? it works 100% of the times on my machine. Why should i make that change ?

 

check the scripting API, StartCoroutine function takes a string as parameter for methodname.. i couldn't really say why it would throw a nullref ex, because i can't see the code behind StartCoroutine
http://docs.unity3d.com/ScriptReference/30_search.html?q=StartCoroutine

 

The first overload of StartCoroutine takes an IEnumerator (also there in the link). That shouldn't matter (unless i am missing something, if so, please explain).

 

ow, my bad... didn't read that (i always just use string, which sounds kinda stupid now...)
in that case.. could you post the exact error you are getting?

 

You are missing nothing. Indeed what you are using is far superior because you are on the safe side when it comes to renaming method names.
Do you have any further details to share regarding the error message?

 

The only error i am getting is the exception:

NullReferenceException in
UnityEngine.MonoBehaviour.StartCoroutine (IEnumerator routine)
The code we use is exactly as i described. This also never happened locally here. I cannot figure out what may be the issue.

 

Sorry, that is just not enough information to help you out. There are far too many unknowns. May it happen that the game object or the component in which the coroutine is supposed to be executed gets destroyed? Is it executed in another game object that might be destroyed? E.g. someOtherMonoBehaviour.StartCoroutine (...). Is it possible that there is a null reference exception within your coroutine?

 

Does OnCompletion return anything? If not, or if null, then basically StartCoroutine(null) is invoked, which is not valid.

 

Sorry to tell you that, but this is not correct.

 

Trying to answer what was said above:

@Dantus

1. The coroutine method is on the same MonoBehaviour (like the example i posted). The object / component is not destroyed (only when the next level is loaded, which is what the coroutine should be doing.
2. Even if there was a null reference in the coroutine, the crash comes from StartCoroutine itself (e.g: my code doesn't run yet).

@SunnySunshine

The coroutine yields (it has to, otherwise it doesn't compile). Even yielding null is OK, and won't result in the IEnumerator being null.

 

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class StartCoro : MonoBehaviour {
5.  
6.     // Use this for initialization
7.     void Start () {
8.         StartCoroutine(Test());
9.     }
10.    
11.     // Update is called once per frame
12.     void Update () {
13.    
14.     }
15.  
16.     IEnumerator Test()
17.     {
18.         return null;
19.     }
20. }
21.  

 

A method returning an IEnumerator doesn't have to yield to compile. But if you're yielding then I don't know what's wrong.

 

I thought that doesn't compile. In any case, i have yield statements in my coroutine, so this is not the case.

 

Keep going guys, maybe something will throw me a lead to the solution

 

Is DownloadSomething a coroutine somewhere else?
I see you're using a delegate there as a callback, any chance this monobehaviour gets destroyed and the callback is called anyway?

 

You should never use "return" on functions that return IEnumerator in Unity - always "yield return" it.
"yield return null" doesn't throw an exception for example.

And Lior, can you please place the actual code that you're doing? Kind of hard to debug it this way.

 

Sorry, I wasn't precise. What I meant is that if you return nothing, it won't compile at all. But you are certainly right about return null.

 

True. I knew I had produced a NullReferenceException by doing something like that, just not which one of my suggestions so I thought I'd mention all possibilities. But indeed not returning will not compile.

 

I met the same error, my script is not bound to the gameObject。After binding is solved