I suggest you ...

Better NullPointerException Error message

Let's say you have the line

a.b().c().d().e().f().g();

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

265 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    llewellyn falcollewellyn falco shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    13 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • AnonAnon 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

      • Todor MutafovTodor 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 BakkerFrank 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 SaundersJohn 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 SpitzZev 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 SpitzZev 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 SaundersJohn 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 LeggettBruce 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

      • InvokerInvoker commented  ·   ·  Flag as inappropriate

        Fully agreed, hate that exception too, really useless. Need to fix.

      • Andre LombardAndre 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.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        I'm usually having a pain of non informative NullReferenceExceptions +2

      Feedback and Knowledge Base