Null conditional operator to "nullify" array element existence

Question

The new C# 6.0 null-conditional operator is a handy vehicle for writing more concise and less convoluted code. Assuming one has an array of customers, then you could get null instead of a length if customers is null using this (examples from MSDN):

int? length = customers?.Length;

Similarly you could get null instead of a customer with this:

Customer first = customers?[0];

And for a more elaborate expression, this yields null if customers is null, the first customer is null, or the first customer's Orders object is null:

int? count = customers?[0]?.Orders?.Count();

But then there is the interesting case of the non-existent customer that the null-conditional operator does not seem to address. We saw above that a null customer is covered, i.e. if an entry in the customers array is null. But that is quite distinct from a non-existent customer, e.g. looking for customer 5 in a 3-element array or customer n in a 0-element list. (Note that the same discussion applies to Dictionary lookup as well.)

It seems to me that the null-conditional operator is focused exclusively on negating the effects of a NullReferenceException; IndexOutOfRangeException or KeyNotFoundException are alone, exposed, cowering in the corner, and needing to fend for themselves! I submit, that in the spirit of the null-conditional operator, it should be able to handle those cases as well... which leads to my question.

Did I miss it? Does the null-conditional provide any elegant way to truly cover this expression...

customers?[0]?.Orders?.Count();

...when there is no zeroth element?

Solution 1

No, because it is a null-conditional operator, not an indexoutofrange-conditional operator and is merely syntactic sugar to something like the following:

int? count = customers?[0]?.Orders?.Count();

if (customers != null && customers[0] != null && customers[0].Orders != null)
{
    int count = customers[0].Orders.Count();
}

You can see that if there is no zeroth customer, you will get your regular IndexOutOfRangeException.

One way you could work around it is to have an extension method that checks for the index and returns null if it doesn't exist:

public static Customer? GetCustomer(this List<Customer> customers, int index)
{
    return customers.ElementAtOrDefault(index); // using System.Linq
}

Then your check could be:

int? count = customers?.GetCustomer(0)?.Orders?.Count();

Solution 2

customers?.FirstOrDefault()?.Orders?.Count();

No zeroeth, no problem.

Solution 3

If you want to get the nth element without having NullReference or IndexOutOfRange exceptions, you can use:

customers?.Skip(n)?.FirstOrDefault()

Solution 4

It doesn't support indexing safety because, when you get down to it, an indexer really is just syntactic sugar for any other type of method.

For example:

public class MyBadArray
{
    public Customer this[int a]
    {
        get
        {
            throw new OutOfMemoryException();
        }
    }
}

var customers = new MyBadArray(); 
int? count = customers?[5]?.Orders?.Count();

Should this be caught here? What if the exception was more sensible, similar to a KeyNotFoundException, but specific to the type of collection we're implementing? We'd have to continually update the ?. functionality to keep up.

Further, ?. does not catch exceptions. It prevents them.

var customer = customers?[5]; is actually compiled as:

Customer customer = null;
if (customers != null)
    customer = customers[5];

Making it catch exceptions becomes exceptionally more difficult. For example:

void Main()
{
    var thing = new MyBadThing(); 
    thing.GetBoss()?.FireSomeone();
}

public class MyBadThing
{
    public class Boss
    {
        public void FireSomeone() 
        { 
            throw new NullReferenceException();
        }
    }
    public Boss GetBoss()
    {
        return new Boss();
    }
}

If it were simply catching exceptions, it would be written as :

Boss boss = customer.GetBoss();
try 
{
    boss.FireSomeone();
} catch (NullReferenceException ex) { 

}

Which would actually catch the exception within FireSomeone, rather than the null reference exception which would be thrown if boss were null.

The same bad-catching problem would be present if we were to catch index lookup exceptions, key not found exceptions, etc.

View more solutions

Comments

[Mephy]

"Null-conditional operator", not "exception globbing operator". Personally I'd consider unintuitive behavior if it bypasses OutOfIndexExceptions/KeyNotFoundException for nulls.

[Rob]

The ?. operator simply wraps the code in if (val != null) { ...//Continue }. IndexOutOfRangeException can come from anywhere, and many classes do indeed throw it. An indexing operation also doesn't necessarily mean an index lookup in terms of traditional arrays, it's also used in dictionaries/lookups/etc. It wouldn't make sense for it to catch this kind of exception.

[Scott Hannen]

Don't fearoeth the zeroeth.

[Michael Sorens]

I actually did end up going with an extension method on Dictionary<TKey, TValue> called ElementAtOrNull that operates in a similar fashion by returning dictionary.ContainsKey(lookupValue) ? dictionary[lookupValue] : null

[Derek]

It might be good to move the ElementAtOrDefault information closer to the top of the answer. It looks like it is a standard function, and does exactly what the user wants.

[ephraim]

you found a sollution to replace the [0] to "FirstOrDefault", but the question was more genral, regarding [index], where index might be out of arrays bounds..

[justromagod]

override operator [] with swallowing ArgumentOutRange exception should work.

[alas]

This is the most elegant solution by far