What was null!? I’m sure you’ve had your share of frustration asking the question, what was null, when receiving an error message in your application stating that you have “An unhandled exception of type ‘System.NullReferenceException’ occurred in…’ and then gave you the name of your exe or dll causing the error. If you’re like me, your response is something like, that is completely useless. I know it happened, and the program causing it. But it doesn’t tell me where in the program, or what the program was trying to do.
So, we handle these kinds of things by wrapping code that may potentially have this kind of error with try/catch, in the hope that we didn’t miss a nullable error somewhere. Then, because we captured the error, we can dig into the code for further research. At least now we know where to look. But, we don’t know what Object (variable) was null, unless the code stands out. Sometimes there are hints we can track down. Other times we simply have to run a trace and review the data using watch variables.
Well, using Visual Studio there is hope in the future. The Dot Net Core team is working with the Visual Studio team. The goal is to be able to expose in Visual Studio the actual object resulting in the error. They have already released the CLR code to enable this feature. When Visual Studio releases their implementation, Null Reference Exception debugging may become a much simpler task.
If you want you can review the blog from the Dot Net Core team who shared this plan at https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/.
Do you use any particular implementation to avoid Null references? How about constructors on all of your classes. Share your thought with use in the comments below.
Cheers,
Ben