I suggest you ...

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

3,003 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
llewellyn falco shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Zev Spitz commented  ·   ·  Flag as inappropriate

    Consider the following Javascript code: var a={}; a.b.c(); which returns the following error (in IE8): "'a.b' is null or not an object"

  • Ted commented  ·   ·  Flag as inappropriate

    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.

  • Dan commented  ·   ·  Flag as inappropriate

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

  • Anon commented  ·   ·  Flag as inappropriate

    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

  • Fred commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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)

  • John Saunders commented  ·   ·  Flag as inappropriate

    @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.

  • Zev Spitz commented  ·   ·  Flag as inappropriate

    @John Saunders: It would also be far more helpful to include the link to your SO answer in the Exception Assistant.

  • Zev Spitz commented  ·   ·  Flag as inappropriate

    @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.'

  • John Saunders commented  ·   ·  Flag as inappropriate

    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.

    Also, see http://stackoverflow.com/questions/4660142/what-is-a-nullreferenceexception-in-net.

  • Bruce Leggett commented  ·   ·  Flag as inappropriate

    Everyone hates the exception. The runtime knows which object was null, so tell the developers so they don't WASTE time troubleshooting

  • Andre Lombard commented  ·   ·  Flag as inappropriate

    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.

2 Next →

Feedback and Knowledge Base