Better NullPointerException Error message
Let's say you have the line
and you run it and get an
System.NullReferenceException: Object reference not set to an instance of an object.
Where did this happen? what do you need to fix?
A better error message would be
The Call: null.e()
Caused a Null Reference Exception
this would make debug/life a lot easier.
I would also suggest you use the full method signature so you might get
The Call: null.e(string, List<string>)
Thank you for using Visual Studio and for your commitment to improving it. We completed this item in Visual Studio 2017.
Read about it here: https://blogs.msdn.microsoft.com/devops/2016/03/31/using-the-new-exception-helper-in-visual-studio-15-preview/
Visual Studio Diagnostics
Drew Noakes commented
Yes, also believe this is fixed in VS2017.
Levente Nagy commented
Seems like it has been implemented in VS2017:
Ryan O'Connor commented
This isn't just an issue with nullreferenceexceptions but ALL exceptions and fluent apis
A lot of .NET guys are feeling abandoned out there today. They see the excitement around cross-platform, or mobile devices, or the cloud.
.Net is the wrong product at the wrong time. That's what happens when you follow rather than lead. Microsoft's Java clone could never hope to be as successful as Java itself.
It is a "already" a thing in Visual Studio "15" Preview 5
This would be pretty useful when helping people who are new to coding. Personally, I don't find Null Reference Exceptions terribly difficult to track down, but it's such a common question to see on help sites, and a bit more information would make it a whole lot easier to steer people towards solutions.
I'd love this.
To address Qwertiy's comment, perhaps the message could be changed to
Null Reference Exception. Could not evaluate "a.b().c().d().e().f().g();" because "a.b().c().d()" is null.
Or using Qwertiy's example:
Could not evaluate "node.Parent.Parent.Parent.Value" because "node.Parent.Parent" is null.
Although, I acknowledge that this is likely much harder to do. Fortunately, using just "null.e()" would be 100% useful in the vast majority of cases as things like "node.Parent.Parent.Parent..." don't come up as often.
i dont get why this isnt a thing yet for .NET.
Present this on the next Connect() event (when unveiling VS "15") - (we know it'll happen then ;) )
and everyone will clap. EVERYONE, WORLDWIDE, EVERYWHERE.
Cmon guys, do it for the claps.
[but on a serious note. wow, this would help so much in tracking issues]
Jeffrey P. Silverstone commented
It would be very useful.
Maybe since you've already done it for C++, but I'm still not voting for this one.
Dror Helper commented
[Disclaimer: I'm affiliated with OzCode]
OzCode (www.oz-code.com) does a good job of predicting NullReferenceException as well as show the offending call.
Column number is better as for smth like
meessage null.Parent is not clear enough.
FYI, ReSharper does an excellent job of pointing out possible NullReferenceExceptions, and of helping you mitigate them by adding null checks.
Yes, it would be nice if an application would provide better details for this error. When errors occur for this one Nightmare application it becomes a gigantic issue with management, and they need to be fixed immediately (an unfortunately that duty sometimes falls to me). Sure, it is easy to say "put null checks", but you cannot do much with an application that you can only maintain. Having more information to really pinpoint the problem would be really beneficial.
And also, having more clear error messages would also benefit development. Developers should be aware of possible null values and deal with them in some way, but still over time I would expect one or two to get past.
does stack trace not return the class method line and column that the null reference was thrown at?
maybe vs is not correctly set up or installed improperly but even the call stack should show were it happened
James, the exception has nothing to do with an IDE. Surely, a tool like ReSharper could help you to rewrite the expression to make it easier to see the NullReferenceException, but at runtime, there is no information that would know what pieces of source code caused the problem.
I agree, it's annoying to get a null exception from a chain of calls, and having to break them apart to find it. Sure, someone could do it, but I thought the whole point of an IDE and proper error reporting was, at least in part, to help move coding along faster. ;) I fact, I figure that's why we have inellisense; ... now, if only the errors that really matter the most are also intelliGENT! ;)
This is quite a good suggestion. To those of you who say "don't pass null, don't return null", I'd like to point out that the original developer is rarely the person who introduces the NRE.
Consider this code:
List<User> friends = user.GetFriendsList();
return friends; // or do something else with friends which might NRE
This code works fine for ages.
Some time later, _someone else_ changes the GetFriendsList() method such that it may return null, and _you_ are the sorry ****** stuck with the null reference exception. This is by far and away the most common way NREs are born, and it would be really useful for _you_ to have this info in the exception so you can find and fix the bug more easily.
Joberto Diniz commented
NullReferenceException and KeyNotFoundException has to be changed!
Zev Spitz commented