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
Joberto Diniz commented
NullReferenceException and KeyNotFoundException has to be changed!
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).
Lars-Erik Aabech commented
Don't pass null, don't return null. Problem solved!
I do not like your example, I would be more concerned with your design practices than the actual exception.
Also for me at least (which I assumed happened to everyone) the offending line is always highlighted, not the method calling it but then I don't method chain the way you do
Exceptions are generally terrible throughout .NET. Take the KeyNotFoundException, for example. It doesn't even tell you what the Key you tried to retrieve was! If you're just logging exceptions, this is very useful information!
I think all those who said that it's unnecessary because you can find the NullReference yourself are ridiculous. We should make everyone's debugging *harder* in the name of encouraging better programming practices?
Exceptions do not contain the contents of local variables, so they should be saddled with as much context about what caused the exception as possible.
Todor Mutafov commented
What would make debugging and your life a lot more easier is writing your code in a way that makes reading and making sense of it easier. If a method can return null, don't chain it.
Frank Bakker commented
I think this would apply to any Exception, not just the NullReferenceException. The stacktrace now does contain the line number but should also include the column where the exception occured.(even though NullReferenceExceptions are the most common place where this happens)
@Zev: yes, but I meant to make a separate suggestion so that it can get votes.
@John Saunders: Isn't this the right place to post suggestions?
@Zev: That's an interesting suggestion. Feel free to directly suggest it to Microsoft. In fact, it suggests a broader feature. The Exception Assistant could come with links to guidance on typical reasons for the exceptions, and it would be interesting if those links could be customized. The Process Guidance in TFS could be a model of how to do this.
@John Saunders: It would also be far more helpful to include the link to your SO answer in the Exception Assistant.
@John Saunders: When you say "it's better to learn...", do you mean it's important for the new developer to understand the underlying cause of a NullReferenceException? Or do you mean it's important for the experienced developer to understand the API he's working with, which might return a null value?
In the average debugging situation, knowing precisely which call returned a null would be extremely useful. Or are you suggesting that we go back to programming in assembly? :)
"Just break up the call chain": Once I've seen the error, wouldn't it be useful to know immediately what steps I can take to fix the error? Instead, you're suggesting it's better to have an intermediate step of breaking up the call chain and rerunning the program to discover the precise call which returned null.
A more convenient workaround would be to successively evaluate each call in the Watch window, although this might introduce side effects of the call.
"since it doesn't know ... that the instance came from a call to 'd'": OK, but at least tell me that I can't call e() on a null reference, instead of telling me 'Somewhere in this line is a call to a member of a null reference -- you figure out which call.'
This is an unworthy request, in my opinion. It's better to learn what causes such exceptions rather than have the CLR try to hold your hand. Also, exactly what would the CLR tell you, since it doesn't know, at the time it tries to access "e", that the instance came from a call to "d".
Just break up the call chain if you need to debug:
va bv = a.b();
var cv = bv.c();
var dv = cv.d();
var ev = dv.e();
var fv = ev.f();
var gv = fv.g();
That makes it pretty easy to see where the null is coming from.
Bruce Leggett commented
Everyone hates the exception. The runtime knows which object was null, so tell the developers so they don't WASTE time troubleshooting
Fully agreed, hate that exception too, really useless. Need to fix.
Andre Lombard commented
While the title says "NullPointerException" the description says NullReferenceException. My vote is for the NullReferenceException, as in "Object reference not set to an instance of an object.". Would be great if the original poster can update the title to match.
I'm usually having a pain of non informative NullReferenceExceptions +2