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 are actively evaluating whether we will be able to bring this suggestion into the product for .NET developers for the System.NullReferenceException in a future release.
We have recently made an improvement, similar to this suggestion, for debugging C++ Access Violations in Visual Studio 2015 Update 1.
Read about it here: http://blogs.msdn.com/b/visualstudioalm/archive/2015/10/29/improvement-to-debugging-c-access-violations-in-visual-studio-2015-update-1.aspx
We encourage you to continue to comment on and vote for this UserVoice item to share any additional feedback that you have for this suggestion.
Visual Studio Diagnostics
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
Please also fix the KeyNotFoundException. I don't understand why after a decade so many Exceptions still return no valuable context information. In production apps all you have is the Exception in some log to try and ascertain the bug.
The best NullReferenceException is the one not thrown, but the next best one is the one which provides enough detail to easily find the bug and fix it. If the data is easy to provide, I see no reason why it shouldn't be added to the exception information.
It is disappointing how much trolling there has been over this issue. Of course all code should be guarding against nulls. However, suggesting the framework should deliberately omit information from the exception as if to punish the coder who wrote it adds nothing to the discussion (and completely ignores how frequently someone else is stuck maintaining the code).