This has never happened to me so I'm a bit confused.

GameObject someObject = Instantiate (Resources.Load ("Prefabs/Items/" + someName)) as GameObject;

This throws an error but the object is actually instantiated and everything works as intended. The error doesn't stop the program no matter how many times I reproduce this.

Can I ignore this error or is there some problem that I'm not seeing?

  • 32
    \$\begingroup\$ you should never ignore errors. They are always there for a reason ;) \$\endgroup\$
    – user115399
    Oct 31, 2018 at 14:19
  • 5
    \$\begingroup\$ I want to second the idea of never ignoring errors just because "it works". By definition, if there's an error, it doesn't work. Sure, it might seem to do everything you want it to, but that just means you haven't found the broken bit yet. \$\endgroup\$
    – anon
    Oct 31, 2018 at 23:03

2 Answers 2


If the object is instantiated correctly despite the Intantiate() line throwing an exception, then the error is coming from another instance of the script — you might accidentally have a second copy in your scene.

One instance is configured correctly, and performing the Instantiate() as expected with no errors, so the object is created as desired.

Another instance is configured incorrectly, and throws an error. But if you're just looking at the correctly-configured instance, this error will seem to come from nowhere and have no visible consequence.

You can print out the path to the object on Start - or in a null check just before the offending line - to help track down unwanted scene duplicates.

You absolutely should not ignore this error.

At best, it's burning compute cycles unnecessarily. At worst, it's a sign that your game is doing something you don't fully understand, and that can be the root of much bigger problems down the line.

  • 12
    \$\begingroup\$ +1, errors are not the same as warnings, if there is an error, you never know when it will escalate to the whole game crashing. \$\endgroup\$ Oct 31, 2018 at 14:10
  • 13
    \$\begingroup\$ It's not always safe to ignore warnings either. Even if it's not an error it could still potentially lead to a situation where the game crashes. \$\endgroup\$ Oct 31, 2018 at 15:51
  • 2
    \$\begingroup\$ I agree with @SeanBurton, ignoring warnings is not a safe practice. You should ignore a warning if, and only if, you understand what is causing it and are comfortable that it is not causing an issue in your code. Even then, ask yourself if you couldn't be doing it better. \$\endgroup\$ Nov 1, 2018 at 15:58
  • 3
    \$\begingroup\$ Every project I've worked on with a large team has at some point gotten so overloaded with "ignorable" warnings that it started to mask genuine issues. So I'd definitely advocate treating warnings seriously too, and if one is unavoidable, disabling it for the relevant line along with a comment clearly defining why it's safe to skip generating the warning there. \$\endgroup\$
    – DMGregory
    Nov 1, 2018 at 16:12
  • 1
    \$\begingroup\$ I'm 100% with @DMGregory, I have only worked on very small teams, but the pair of times warnings started to stack it was horrible to find "genuine" issues, or you'd miss them all the time. My MO is to keep the log clean except for testing, even if I have to disable warnings on plugins' code (please, don't make plugins with warnings EVER), it's much much better in the long run IMO. Edit: to be clear, never disable warnings unless you're 100% sure there's no other way around (which happens 0.001% of the time), always actually fix them. \$\endgroup\$
    – Trisibo
    Nov 1, 2018 at 18:19


Let me start off by answering your question directly:

it works, can I ignore the error?

You could. You should not, because it means something is going wrong. You would get used to this error, but it could "hide" or cause another error.

Currently you have an error message and it still works correctly. The other way around, it not working and not having (or rather: not recognising) feedback why, is far worse!


To find out where this comes from, split this whole thing up into several lines.

string resourceLocation = "Prefabs/Items/" + someName;
Object prefab = Resources.Load(resourceLocation);
Object instance = Instantiate(prefab);
GameObject someObject = instance as GameObject;

An error only tells you at which line it happened. If the error happens in this code, the line number will tell you more about which part went wrong here. Also, I'd advise using the generic version of Resources.Load, that would actually give us one step less to worry about:

string resourceLocation = "Prefabs/Items/" + someName;
GameObject prefab = Resources.Load<GameObject>(resourceLocation);
GameObject someObject = Instantiate(prefab);

Finding out why

  • Now, a bit of Unity experience tells us that “The Object you want to Instantiate is null” is caused by Instantiate().
  • So, that means prefab is null.
  • So that means Resources.Load returns null.
  • The documentation for Resources.Load says "Returns the asset at path if it can be found otherwise returns null."
  • So that means it doesn't find the given path (the string I called resourceLocation)

Something is wrong with this path, so the obvious first step would be to see what it actually ends up being, with Debug.Log. As "everything works as intended", its probable that there is some duplication going on where one version works and the other gives you this error.

In that case, it's a good idea to use the 2 parameter version of Debug.Log Debug.Log(resourceLocation, gameObject);. Now if you click on the log message in the Unity editor, it will select the GameObject where it came from.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .