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.