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)
  • Carl Walsh commented  ·   ·  Flag as inappropriate

    @OnlyWhileDebugging Agreed, nothing about the exception has changed, and this information is only available when the debugger breaks on the exception. If you don't have first chance exception debugging turned on and the null-ref doesn't kill your application, you don't get the info.

    I don't care about assistance debugging a null-ref when i'm attached in the debugger, I care about understanding a stack-trace from code that's running on machines I don't own. Customers are willing to run Debug builds, but even with this feature I'd still be forced to either help them set up a debugger, or create a new custom build with printf debugging.

    I think this needs to be fixed at the runtime or the compiler level, and not the debugger...

  • OnlyWhileDebugging commented  ·   ·  Flag as inappropriate

    This is not completed.

    The NullReferenceException message has not changed...

    ...and "It is only available *while debugging* code that does not have any Just-In-Time (JIT) code optimizations."

  • Anonymous commented  ·   ·  Flag as inappropriate

    A lot of .NET guys are feeling abandoned out there today. They see the excitement around cross-platform, or mobile devices, or the cloud.

    .Net is the wrong product at the wrong time. That's what happens when you follow rather than lead. Microsoft's Java clone could never hope to be as successful as Java itself.

  • Shaggy commented  ·   ·  Flag as inappropriate

    This would be pretty useful when helping people who are new to coding. Personally, I don't find Null Reference Exceptions terribly difficult to track down, but it's such a common question to see on help sites, and a bit more information would make it a whole lot easier to steer people towards solutions.

  • David commented  ·   ·  Flag as inappropriate

    I'd love this.

    To address Qwertiy's comment, perhaps the message could be changed to

    Null Reference Exception. Could not evaluate "a.b().c().d().e().f().g();" because "a.b().c().d()" is null.

    Or using Qwertiy's example:

    Could not evaluate "node.Parent.Parent.Parent.Value" because "node.Parent.Parent" is null.

    Although, I acknowledge that this is likely much harder to do. Fortunately, using just "null.e()" would be 100% useful in the vast majority of cases as things like "node.Parent.Parent.Parent..." don't come up as often.

  • SomeRandomDude commented  ·   ·  Flag as inappropriate

    i dont get why this isnt a thing yet for .NET.

    Present this on the next Connect() event (when unveiling VS "15") - (we know it'll happen then ;) )
    and everyone will clap. EVERYONE, WORLDWIDE, EVERYWHERE.

    Cmon guys, do it for the claps.

    [but on a serious note. wow, this would help so much in tracking issues]

  • Qwertiy commented  ·   ·  Flag as inappropriate

    Column number is better as for smth like
    meessage null.Parent is not clear enough.

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

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

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

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

← Previous 1

Feedback and Knowledge Base