int? count = customers?[0]?.Orders?.Count();
Pragmatic features like this are one reason why I love C#. I get the feeling that language designers are actually looking at real world code and thinking what kind of features would be it better.
My rule of thumb is that ?. is OK to use when
1) The reference is expected to occasionally be null in the course of normal operations
2) You legitimately don't care if the reference is unexpectedly null, as you wouldn't or couldn't fix it even if you knew about it
Otherwise it's better to discover and fix the NullReferenceException ASAP.
Assert.That(r.Exception?.InnerException?.Message, Is.EqualTo("Exception result"));
config?.OutputName ?? DefaultConfig.OutputName
Invoke Action<> or Func<> that may be null or unassigned (this works for Events as well):
actionHandler?.Invoke(value);
items.First()?.Data
items.FirstOrDefault(item => item.Data != null)?.Data items.First()?.Data
The rest of your samples look fine to me though.
[1] - https://msdn.microsoft.com/en-us/library/dn986595.aspx
I'm not justifying buggy code, but these days we do handle more objects-per-debug-line-number than we used to.
new string[] { "1", null }.Select(s => s.Length).ToList();
It's helpful to have the actual thing that's null for post-error troubleshooting.
Not necessarily. Take a look at LINQ, for example.
public Result MapResult(IntermediateType src)
{
return new Result
{
Property1 = src.Property1,
Property2 = src.Indirection.Property,
[...]
};
}
public Result MapResult(IntermediateType src)
=> new Result
{
Property1 = src.Property1,
Property2 = src.Indirection.Property,
[...]
};
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
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".
function frob(foo) {
return (foo && foo.ary || [])
.map(...)
}
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.
It's best to make it impossible to call your function with the wrong kind of thing, but Javascript doesn't have a type system. Still though, if their code has gotten into a nonsense state, better to throw an exception (or whatever the language-standard way of handling errors is) than silently carry on. Otherwise they can spend up hours debugging their filtering logic wondering why it's started filtering everything out, when in fact the server they were calling into has started sending 1-element responses as not an array which your code then silently changes into an empty array.
> 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.
If you propagate garbage you're part of the problem. Defensiveness goes hand-in-hand with fail-fast.
> Just like an HTTP server shouldn't crash because someone sends it data that should return a 4xx response.
Right but if your query was malformed you should get a 4xx, not a 200 with no results. (This is one reason I think it's actually a bad idea to use 404 for when there's no item with that ID - it makes it hard for the client to tell the difference between "I called the API wrong" and "I called the API correctly but there are no results").
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.
See slide 17 of https://oracleus.activeevents.com/2014/connect/fileDownload/...
Though I do recall a long time ago reading about some JVM switches that allow that data to be accessed but with performance issues. Can't recall where I read that.
Would love to know how to do that.
I hope I will be wrong.
ps: a language where non-nullable references are the thing would be the best.
As I see: unfortunately without algebraic types you cannot solve this properly, even if you address the lacking points in Optional<T>
That being said, better late than never.