5 ms·

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.

It does when it has a bug in it...

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.