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>)
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!
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.'