Кажется, я столкнулся с серьезными проблемами с NullReferenceExceptions.

Похоже, вы не знаете, что делать, если вы получаете неверные параметры в своих методах. По сути, в том, что вы делаете сейчас, нет ничего плохого, но более распространенным шаблоном является проверка параметров в заголовке вашего метода, выдача исключения, если они не такие, как вы ожидаете:

if (list == null)
{
    throw new ArgumentNullException(list);
}

Это распространенный шаблон защитного программирования - убедитесь, что предоставленные вами данные проходят базовую проверку работоспособности.

Теперь, если вы сами явно вызываете этот метод и обнаруживаете, что этот метод получает нулевой параметр list, когда вы этого не ожидаете, пора взглянуть на логику вызывающего метода. Лично я предпочитаю передавать пустой список, когда у меня нет элементов, в отличие от null, чтобы избежать особых случаев, подобных этому.

Я, вероятно, собираюсь получить отрицательное голосование от толпы "без множественного выхода", но я обычно справляюсь с этим с помощью простой проверки в самом начале метода:

if (list == null || list.Count == 0) return;

это определяет условия выхода, и тогда вам не нужно беспокоиться о нескольких уровнях отступа в вашем методе. Это работает только в том случае, если вы можете позволить себе проглотить тот факт, что ваш список пуст или равен нулю, что может случиться в некоторых случаях.

Но я согласен с кодекой в ​​том, что вам нужно посмотреть на вызывающий код и подумать, можно ли его улучшить оттуда.

Похоже, что защитное программирование и проверка параметров - это то, что вы ищете.

Как говорили другие, для вас подойдет простая проверка параметров:

if (list == null)
    throw new ArgumentNullException("list");

В качестве альтернативы, если вы устали постоянно писать подобные проверки для каждого параметра, вы можете проверить одну из многих библиотек принудительного исполнения предварительных условий .NET с открытым исходным кодом. Мне нравятся CuttingEdge.Conditions.

Таким образом, вы можете использовать что-то вроде этого:

Condition.Requires(list, "list").IsNotNull();

Однако настройка предварительного условия, подобного любому из вышеперечисленных, просто укажет, что ваш метод не принимает значения NULL. Ваша проблема по-прежнему будет заключаться в том, что вы передаете в метод значения NULL! Чтобы исправить это, вам нужно будет проверить, что вызывает ваши методы, и выяснить, почему передаются нулевые объекты.

Помимо выдачи исключений ArgumentNullException, существует также нечто, называемое «Null Obejct Pattern», которое вы можете использовать, если хотите, чтобы передавал нулевое значение, например, чтобы указать, что чего-то не существует, но не хочу явно проверять нули. По сути, это класс-заглушка, который реализует тот же интерфейс, но его методы обычно либо пусты, либо возвращают ровно столько, чтобы они завершились. http://en.wikipedia.org/wiki/Null_Object_pattern

Также полезно для типов значений, которые не могут легко выразить свое несуществование, не имея возможности иметь значение NULL.

Я бы вернулся раньше (или выбросил бы InvalidArgumentException раньше), если бы получил недопустимый ввод.

Например:

private void SetUserFriends(List<Friend> list) 
{ 
    if (list == null) 
        return;

    /* Do stuff */
}

В качестве альтернативы вы можете использовать общий шаблон объединения NULL:

private void SetUserFriends(List<Friend> list) 
{ 
    list = list ?? new List<Friend>();

    /* Do Stuff */
}

Вы действительно задаете неправильный вопрос. Правильный вопрос: «представляет ли null недопустимый ввод или флаг, который означает X».

Пока в язык не будут добавлены ненулевые ссылочные типы и не появятся различные API, у вас есть выбор: сделать это явным в коде или разрешить пустые ссылочные исключения помочь вам найти, где ожидание нарушено, а затем исправить данные / код. так или иначе.