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>)
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
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