I’m almost embarrassed to ask at this point but can’t miss out if this feature exists:
When I get a null reference exception, is there anyway to see which reference exactly is null? console just shows me the line, but often times there are several references in that line. So I have to do some testing to find out which one it actually is. It would greatly improve my workflow to see which one directly.
Anyway to see it? Any crazy workaround, paid tools, whatever.
Thanks
(And sorry for making a new thread, googling anything related to null ref is pretty hard given the amount of questions floating around the web).
Not really, it just says to add null checks to the code, but I can’t do that for every time I use a reference. I just wish the console would print a null reference with the line AND the reference that was null by default.
Fastest way I know of is using a break point and go over the variables. But it’s frustrating because I assume Unity already has that info when the game breaks, it just doesn’t want to tell it to me…
Sometimes you can see the reference by clicking on it but other times it’s private and you have to retrace your steps
one tip is that if you suspect a particular for loop or list is responsible, then check your values in that loop. Or throw a debug log in there to find out which value poses the problem.
the culprits that you are not told about are things that you wouldn’t assign via inspector. So it won’t jump you to the location of the for loop that broke but it would take you to the location of the function that initiated it.
If the data cannot be found or located then I am afraid the solution is to throw a debug log at every important interval between your codes and go to the position of the last debug that called before the error ocurred
tip turn on pause on error in the console.
one thing if you went through a function, to access a for loop, the line data remains the same while the function runs. So it will take you to the line point when you entered the function. Which means, it won’t point to the exact error location because this function is considered part of the line of the entrance to that function. So the entire function may be treated as a line. Hence the debug log offering a method to locate the specific line of code manually.
You activate it via the little menu button at the top-right of the Inspector window, and (among other things) it lets you see the value of private member variables.
Handy in cases where one or more of the potential culprits are member variables.
Pro tip, Debug.Log and similar methods have overloads that take a context object that’s sending the debug. If you provide this context object, the object will be selected in the hierarchy/project files when you click the debug in your console.
Makes it super easy to know what’s the problem object, though only if you’re working with anything UnityEngine.Object derived.
It’s easier to debug things when you reduce the number of things each line is doing. If you do a.b.c.d.e.dosomething() it’s hard to figure out which one is a null, it’s better to store each one in separate local variables.
I also put few instructions in a line and when I get hit by a null ref exception I put a breakpoint to the problematic line and try to reproduce the issue, then see the references in the debugger when I hit that breakpoint.
Also a bit more wonky workaround is to Debug.Log all references in your problematic line and then in the log just above the exception you’ll see which reference was null I rarely use this though.
Thanks, good advice! I’m still trying to get over that phase where I feel smart for putting lots of stuff in one line and pat myself on the back for keeping a script’s line count low. I’ll try to move to the stage where I put things in one line AND keep the line count low
You should switch to an editor that doesn’t charge you by the line!
The computer is an idiot and will blindly do exactly what you tell it, including all misinterpretations and mistakes and “telephone game” misunderstandings along the way.
If you were giving the computer a gun and teaching the computer how to use it, would you just say “Here’s a gun, load it, cock it, point it at the target and pull the trigger as many times as you need!” and hope for the best?
As game developers we should all be thankful we’re not writing software that could hurt someone!
This is an old thread, but I just wanted to jump in and say that it is not an unreasonable ask for a runtime to tell you exactly which reference is null. Every single other environment/compiler/runtime I’ve ever used does this when reporting a null reference exception. Literally every one. Like, Flash does this. Why can’t Unity do it?
I’m sure there is an actual reason (the people who work on Unity aren’t idiots), but day-to-day it’s probably the single dumbest thing about working in Unity.
Also, hey, it’s fine to have a some extra dots in a line of code. We’re not assembly programmers, we don’t need to optimize everything (you’re often just “pre-doing” the compiler’s work, anyway), and laying down a trail of cached variables is often a waste of your valuable time (unless you really do need to cache a variable, it’s usually faster to put in a series of Debug.Logs to suss out your null).
I mean a null ref is a C# error, not a Unity error, so I don’t think the issue here is Unity can’t tell us, it’s just how C# is.
And yes you should still break down code into smaller chunks and not string a bunch of calls together. The readability and debugability will save you substantial time in the long time.
In the mean time I’ve made a simple script that goes through all components of all objects in a scene and checks for public or serialized private fields that are null. I keep the inspector tab of that script on the side and locked. Saved me a lot of time already, seeing right away where I forgot to assign a field, which is like 90% of my null ref errors.
And since I originally asked this question I’m a lot more careful of not packing too many things in one line.
If that’s true, then so be it, but it’s still bonkers when other runtimes have reported the name of the reference to users for decades.
That’s dogma. Sometimes it certainly will save you time, and sometimes it really doesn’t. Like reaallly doesn’t. And when you have a complex data structure and/or you’re managing (and commenting) your own sprawling API, readability is not helped by piling on a bunch of local names for things all over the place. Besides, returns exist to be used, stringing together a bunch of calls can be perfectly good practice.
“Always do” or “don’t ever” is not good advice. And I’m very irritated by “doctor it hurts when I turn my head/well then don’t do that” solutions.
Do it as long as it helps (and/or it feels good and fits your style), but feel free to not do it when it’s a hassle, or when a few log statements or simple deduction will do instead.
You read my statement as dogma but it was just an ‘in general’ statement. Nonetheless it’s still good practice. Break it down, make it readable. Make life for future you easier. Then you’ll have this issue exactly zero times.
Not saying don’t chain extension methods together where applicable, or run through two or three properties where it won’t be an issue. But just do what you need to do to make your code clean, readable and easy to debug.
As an aside comments generally aren’t needed if your code reads easy. I use only comments where I’m doing something weird where the intent can’t easily be discerned just by reading what the code does.
I agree with all the above about writing clean readable code, but the reason for that shouldn’t be a lack of Unity’s UX.
Anyhow, no point in complaining, I don’t think Unity will improve UX and workflows in a meaningful way. Hence I’m making little tools and using stuff like Odin Inspector, Rider etc. And keeping the number of reference variables per line low
I rarely use this though.
