20

Stack traces for NullReferenceException is very uninformative, they just include the method name and the call stack. Any variable in a method can be null and it's hard to debug when the bug isn't reproducible on the dev machine.

Do you know a way to get more info on that error, getting the variable name perhaps? Or do you have better ways to debug it?

Elmo
  • 6,409
  • 16
  • 72
  • 140
  • 1
    You cannot get the variable name. You can determine the line where exception occured. – Alex Dec 23 '15 at 19:30
  • @Alex Yes but in production that requires distributing the .pdb file. And this also prevents the use of obfuscators. – Elmo Dec 23 '15 at 19:31
  • 4
    @Elmo Good luck then. If you're using obfuscators the stack trace is going to be garbage. – Aaron Carlson Dec 23 '15 at 19:32
  • @AaronCarlson My obfuscator lets me turn the stack trace back into the real names. It doesn't modify program structures, just renames everything. – Elmo Dec 23 '15 at 19:37
  • Depending on the obfuscator you're using and if you've been saving off the PDB's generated from the obfuscator you should be able to remote debug the code in action. – Aaron Carlson Dec 23 '15 at 19:37
  • https://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx ... you can always just work to prevent nullreferenceexceptions. – Matthew Whited Dec 23 '15 at 19:44

1 Answers1

17

Keeping track of that name is not always possible (it could be an expression).
And where it is possible it would incur unacceptable overhead. Consider that the runtime would have to track almost all reference variables, that would be costly and prohibit all sorts of optimizations.

Also see my answer on Inspect the managed stack and the Blog post it refers to.

The simple solution is to build in more consistent null checking in your own code:

void Foo(Bar b)
{
   if (b == null) throw new ArgumentNullException(nameof(b));

   ...
}
Community
  • 1
  • 1
H H
  • 263,252
  • 30
  • 330
  • 514
  • Especially useful if you include `Debug.AssertNonNull` (or whatever it should be) just for sanity checking as you debug later. – D. Ben Knoble Dec 23 '15 at 20:12
  • 2
    what's the problem of overhead in debug state? – ahmadali shafiee Jan 07 '18 at 06:22
  • 3
    How is adding the explicit null check and the nameof call a huge overhead? Are you saying for size optimisation? I'd rather be in control of that choice if it were just a compilation flag. This is the big problem with these managed platforms where Microsoft decides what is important for us. We've had to fight tooth and nail for control over large object heap collection. We were prohibited from doing anything about it because Microsoft in their infinite wisdom deemed the "feature" not necessary for YEARS. Not good enough. I have the space. I want the option. – Shiv Apr 15 '19 at 00:52
  • As an added note if you use JetBrains.Annotations and ReSharper, there is an (optional) keyboard shortcut on ! and ? to add the `NotNull` and `CanBeNull` attribute (respectively), and re-hitting "!" on a parameter with the notnull attribute auto-adds this very nullcheck so you don't need to write it yourself. – jeromej Jul 17 '20 at 09:49