4 ms·

Is that really such a sorely missed feature? I tend to need just a quick glance at the offending line to isolate potential null references and in more severe ca

• dimgl 10y ago
  Once you're experienced and writing better code, this isn't a crucial feature. It does help when you've got coworkers who write classes with 20,000 lines however (not an exaggeration, I've actually seen this).
• niftich 10y ago
  I'd imagine that with the rise of the 'fluent' API style of foo.bar().baz().doThis().doThat(toThis).doAnother(toThat); the number of potential null-references per line has gone up from the days when we were all writing code with mutator methods that returned void.
  • gnaritas 10y ago
    The Fluent API styles is to return "this" so setter methods can be chained, that style doesn't produce nulls.
    • AndrewDucker 10y ago
      It does when it has a bug in it...
    • niftich 10y ago
      Yes, but any of the passed-in arguments can be null if they are de-referenced without checking, or you can muck up your context by doing something weird. I'm not justifying buggy code, but these days we do handle more objects-per-debug-line-number than we used to.
      • tracker1 10y ago
        Especially in lambda expressions for LINQ methods...
        • ygra 10y ago
          But you can already debug inside lambda expressions. E.g. for new string[] { "1", null }.Select(s => s.Length).ToList(); VS has no trouble at all telling me the statement that caused the NRE and I can inspect variables local to the lambda as well.
          • pionar 10y ago
            But you can't always debug code that's out in the wild with the same exact scenario that caused the NRE. It's helpful to have the actual thing that's null for post-error troubleshooting.
            • ygra 10y ago
              The whole discussion is about a debugger feature, or at least, the runtime groundwork required for said debugger feature. It will not result in the exception message telling you the null reference's name. It enables an attached debugger to query the runtime for additional information to determine that.
    • fuzzy2 10y ago
      > return this Not necessarily. Take a look at LINQ, for example.
      • gnaritas 10y ago
        LINQ is not a fluent programming style, LINQ is standard functional programming with higher order functions. Chaining calls back to back isn't what fluent is, chaining calls to the same object back to back is fluent whereas with LINQ each call returns a whole new object or set of objects; these are entirely different things. The fluent style is an attempt to emulate Smalltalk's cascade operator in languages that lack it by returning "this" from setters enabling a chain of setters to be called on the same object: that's all it is. This style has been idiomatic to Smalltalk since the 70's and doesn't require faking it because there's actually a cascade operator.
• mattmanser 10y ago
  It was constant, especially in older code bases or anything involving SOAP responses with crappy WSDLs. I'm surprised you've honestly never opened an error call stack and gone "I wish I knew which one it was that is null".
  • ygra 10y ago
    These days I actually cannot recall when that happened to me the last time, hence my curiosity. I remember null pointer dereferences in C++ on Android being impossible to debug, but honestly cannot recall the same for C# in VS. Might be that we simply don't write code that's susceptible to that problem (writing libraries ideas of applications makes you kinda defensive sometimes), or maybe that our code is often a bit conservative out of necessity, so no C# 6 features yet (others have pointed out that certain constructs are prone to let you guess on which line it happened).
    • tracker1 10y ago
      It's funny, but with JS I write pretty defensively to prevent null references... function frob(foo) { return (foo && foo.ary || []) .map(...) } Even though I know everything that will call frob exists and has ary, that doesn't mean it won't change or work otherwise... one of the things I like about how shorting works in JS... though the "?" conditional null thing in C# is pretty damned close.
      • lmm 10y ago
        That ends up worse than null because the actual error will happen even further away when some value is surprisingly []. You want to fail fast in cases where your state no longer makes sense. (This is why naive use of options can end up worse than null).
        • tracker1 10y ago
          If the function ALWAYS returns an array, then so be it. If someone's response to my function can't handle an empty array, then their method probably has other issues, and they should check their own data before calling into it. I'll do other methods that will return an appropriate value, or null. In this way, if you can be defensive in your own code, you aren't the one called when someone hands you garbage. Just like an HTTP server shouldn't crash because someone sends it data that should return a 4xx response.
• daigoba66 10y ago
  In optimized code, in object initializers, or even within lambda expressions, the line number is effectively useless. So troubleshooting production exceptions is usually a game of guess-and-check. As a result, many teams are heavy handed with null checks and ArgumentExceptions if only to make debugging easier in crappy code.
  • douche 10y ago
    Yup, can confirm. Release builds usually have nearly all useful stack information stripped out, so if you get a NRE, you're kind of left playing pin-the-tail-on-the-donkey guessing at what might have been null, without null-checks and asserts.
• martinald 10y ago
  You could use that argument with any slightly-better debugging feature. It's not groundbreaking but will save a few seconds/minutes each time from darting around. It adds up after a while and I bet after the next release of VS has it it looks backwards not having it.
• flukus 10y ago
  The code your debugging isn't always line for line compatible with the code where/when the exception was thrown.
• moogly 10y ago
  Common, popular, coding styles with a lot of inlined code instead of temporaries will have this issue: public Result MapResult(IntermediateType src) { return new Result { Property1 = src.Property1, Property2 = src.Indirection.Property, [...] }; } or, in C# 6 public Result MapResult(IntermediateType src) => new Result { Property1 = src.Property1, Property2 = src.Indirection.Property, [...] }; if Indirection is null here (or indeed anything that can throw an NRE within the initializer), the NRE will reference the line starting with return/=>
  • kmc059000 10y ago
    This is usually where I get NREs too and is the most frustrating. When using object initializers, the line number is the same for the entire initializer, so you don't get much help in determining exactly which line the exception was on. I imagine there is a reason why it's hard, but it seems like it should be easy and incredibly valuable to know which property assignment caused the exception. Regardless, I agree that this is a major source of NREs
  • ygra 10y ago
    Good point, thank you. We're still rather conservative, so except for nameof I haven't yet used any C# 6 features, and the code we write often doesn't look like that, so I tend to forget a few problematic styles sometimes.
• Someone 10y ago
  "in more severe cases just check the tool tips of expressions." There are no such tool tips when looking at log files. If this problem happens rarely or only in production, that oftentimes is the only thing you have. Even if there are just two potential null references on the offending line, one of which seems unlikely, knowing for sure that it is the other one will speed up finding the root cause.
  • ygra 10y ago
    But you don't have a Visual Studio debugger in log files either. This change is about runtime improvements that would enable a debugger to tell you the offending null reference. This won't change the exception message or anything about the exception itself.
    • Someone 10y ago
      For me, anything that produces a stack trace should use that information. IIS can be configured to do that.