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

1,002 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 →

    25 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...
      • John SaundersJohn Saunders commented  ·   ·  Flag as inappropriate

        FYI, ReSharper does an excellent job of pointing out possible NullReferenceExceptions, and of helping you mitigate them by adding null checks.

      • mzmz commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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

      • John SaundersJohn Saunders commented  ·   ·  Flag as inappropriate

        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.

      • JamesJames commented  ·   ·  Flag as inappropriate

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

      • gzakgzak commented  ·   ·  Flag as inappropriate

        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[0]; // 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.

      • Zev SpitzZev 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"

      • TedTed 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.

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

      • 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

      • FredFred 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 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.'

      ← Previous 1

      Feedback and Knowledge Base