Разумно ли ожидать, что Any () * not * выдаст исключение нулевой ссылки?

Когда вы создаете метод расширения, вы, конечно, можете вызывать его в null.But, но в отличие от вызова метода экземпляра, для вызова его в null не нужно бросать NullReferenceException-> вы должны проверять и выбрасывать его вручную.

Для реализации метода расширения Linq Any()Microsoft решила, что они должны добавить ArgumentNullException( https://github.com/dotnet/corefx/blob/master/src/System.Linq/src/System/Linq/AnyAll.cs ).

Меня раздражает необходимость писать if( myCollection != null && myCollection.Any() )

Я не прав, как клиент этого кода, ожидать, что, например, ((int[])null).Any()должен вернуться false?

У меня есть сумка с пятью картошками. В .Any()сумке есть картошка?

« Да », говорите вы.<= true

Я вынимаю всю картошку и ем ее. В .Any()сумке есть картошка?

« Нет », говорите вы.<= false

Я полностью сжигаю сумку в огне. В .Any()сумке сейчас картошка?

" Там нет сумки ".<= ArgumentNullException

Во-первых, кажется, что этот исходный код будет выбрасывать ArgumentNullException, а не NullReferenceException.

Тем не менее, во многих случаях вы уже знаете, что ваша коллекция не равна нулю, потому что этот код вызывается только из кода, который знает, что коллекция уже существует, поэтому вам не нужно будет очень часто ставить там проверку на ноль. Но если вы не знаете, что он существует, то имеет смысл проверить, прежде чем вызывать Any()его.

Я не прав, как клиент этого кода, ожидать, что, например, ((int[])null).Any()должен вернуться false?

Да. Вопрос, который Any()отвечает, "содержит ли эта коллекция какие-либо элементы?" Если эта коллекция не существует, то вопрос сам по себе бессмысленный; он не может ни содержать, ни не содержать ничего, потому что он не существует.

Нуль означает отсутствие информации, а не элементов.

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

Если вы возвращаете null в некоторых случаях, вы можете изменить это, чтобы вернуть пустую коллекцию. (В противном случае, если вы находите нулевые значения, возвращаемые библиотечными методами (не вашими), это прискорбно, и я бы обернул их для нормализации.)

Смотрите также https://stackoverflow.com/questions/1191919/what-does-linq-return-when-the-results-are-empty

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

Рассмотрим функцию, которая принимает коллекцию в качестве параметра. Если для целей функции nullи empty эквивалентны, вы можете убедиться, что он никогда не содержит nullв начале:

public MyResult DoSomething(int a, IEnumerable<string> words)
{
    words = words ?? Enumerable.Empty<string>();

    if (!words.Any())
    {
        ...

Вы можете сделать то же самое, когда извлекаете коллекции из другого метода:

var words = GetWords() ?? Enumerable.Empty<string>();

(Обратите внимание , что в тех случаях , когда у вас есть контроль над функцией , как GetWordsи nullэквивалентно пустой коллекции, предпочтительно , чтобы просто вернуть пустую коллекцию в первую очередь.)

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

Являюсь ли я ошибочным, как клиент этого кода, ожидать, что eg ((int []) null) .Any () должен возвращать false?

Да, просто потому, что вы находитесь на C #, и это поведение хорошо определено и задокументировано.

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

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

Если повторяющиеся проверки на нуль раздражают вас, вы можете создать свой собственный метод расширения IsNullOrEmpty (), чтобы отразить метод String по этому имени и обернуть вызовы null-check и .Any () в один вызов.

В противном случае решение, упомянутое @ 17 из 26 в комментарии к вашему вопросу, будет короче, чем «стандартный» метод, и будет достаточно понятным для любого, кто знаком с новым нулевым условным синтаксисом.

if(myCollection?.Any() == true)

Являюсь ли я ошибочным, как клиент этого кода, ожидать, что eg ((int []) null) .Any () должен возвращать false?

Если вы задаетесь вопросом об ожиданиях, вы должны думать о намерениях.

null означает что-то очень отличное от Enumerable.Empty<T>

Как упоминалось в ответе Эрика Эйдта , существует разница в значении между nullпустой коллекцией.

Давайте сначала взглянем на то, как они должны использоваться.

В книге « Рекомендации по проектированию фреймворка: условные обозначения , идиомы и шаблоны для многократно используемых библиотек .NET», 2-е издание, написанное архитекторами Microsoft Кшиштофом Квалиной и Брэдом Абрамсом, изложены следующие рекомендации:

X НЕ возвращает нулевые значения из свойств коллекции или из методов, возвращающих коллекции. Вместо этого верните пустую коллекцию или пустой массив.

Представьте себе, что вы вызываете метод, который в конечном итоге получает данные из базы данных: если вы получаете пустой массив, или Enumerable.Empty<T>это просто означает, что ваше пробное пространство пусто, т.е. ваш результат - пустой набор . Однако получение nullв этом контексте означало бы состояние ошибки .

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

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

Являюсь ли я ошибочным, как клиент этого кода, ожидать, что eg ((int []) null) .Any () должен возвращать false?

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

Учитывая, что Any()без предиката, по сути, Count() > 0то, что вы ожидаете от этого фрагмента?

List<int> list = null;
if (list.Count > 0) {}

Или общий:

List<int> list = null;
if (list.Foo()) {}

Я полагаю, вы ожидаете NullReferenceException.

• Any()это метод расширения, он должен плавно интегрироваться с расширенным объектом, тогда выдача исключения - наименее удивительная вещь.
• Не каждый язык .NET поддерживает методы расширения.
• Вы всегда можете позвонить Enumerable.Any(null)и там вы точно ожидаете ArgumentNullException. Это тот же метод, и он должен соответствовать - возможно - почти ВСЕМУ другому в Framework.
• Доступ к nullобъекту является ошибкой программирования , фреймворк не должен использовать нулевое значение как магическое значение . Если вы используете это таким образом, то это ваша ответственность, чтобы справиться с этим.
• Это самоуверенно , ты думаешь одно, а я - другое. Рамки должны быть как можно более незавершенными.
• Если у вас есть особый случай, то вы должны быть последовательными : вы должны принимать все более и более взвешенные решения относительно всех других методов расширения: если Count()решение кажется легким, то Where()это не так. Как насчет Max()? Он выбрасывает исключение для ПУСТОГО списка, разве не для nullодного?

То, что разработчики библиотек делали до LINQ, заключалось в том, чтобы вводить явные методы, когда nullэто допустимое значение (например String.IsNullOrEmpty()), тогда они ДОЛЖНЫ соответствовать существующей философии проектирования . Тем не менее, даже если написать довольно тривиально, два метода EmptyIfNull()и EmptyOrNull()могут быть полезны.

Джим должен оставлять картошку в каждой сумке. Иначе я его убью.

У Джима есть сумка с пятью картошками. В .Any()сумке есть картошка?

«Да», говорите вы. <= правда

Итак, Джим живет в этот раз.

Джим достает всю картошку и ест ее. Есть ли в сумке картошка .Any ()?

«Нет», говорите вы. <= ложь

Время убивать Джима.

Джим полностью сжигает сумку в огне. Есть ли в сумке картошка .Any ()?

"Там нет сумки." <= ArgumentNullException

Должен ли Джим жить или умереть? Ну, мы не ожидали этого, поэтому мне нужно решение. Позволить Джиму избежать этой ошибки или нет?

Вы можете использовать аннотации, чтобы сигнализировать, что вы не миритесь с нулевыми махинациями таким образом.

public bool Any( [NotNull] List bag ) 

Но ваша цепочка инструментов должна это поддерживать. Что означает, что вы, вероятно, все равно будете в конечном итоге писать чеки.

Если это вас так сильно беспокоит, я предлагаю простой метод расширения.

static public IEnumerable<T> NullToEmpty<T>(this IEnumerable<T> source)
{
    return (source == null) ? Enumerable.Empty<T>() : source;
}

Теперь вы можете сделать это:

List<string> list = null;
var flag = list.NullToEmpty().Any( s => s == "Foo" );

... и флаг будет установлен в false.

Это вопрос о методах расширения C # и их философии проектирования, поэтому я думаю, что лучший способ ответить на этот вопрос - процитировать документацию MSDN о целях методов расширения :

Методы расширения позволяют вам «добавлять» методы к существующим типам, не создавая новый производный тип, не перекомпилируя или иным образом не изменяя исходный тип. Методы расширения представляют собой особый вид статического метода, но они вызываются так, как если бы они были методами экземпляра в расширенном типе. Для клиентского кода, написанного на C #, F # и Visual Basic, нет очевидной разницы между вызовом метода расширения и методами, которые фактически определены в типе.

...

В общем, мы рекомендуем вам применять методы расширения экономно и только тогда, когда это необходимо. Когда это возможно, клиентский код, который должен расширять существующий тип, должен делать это путем создания нового типа, производного от существующего типа. Для получения дополнительной информации см. Наследование.

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

Если вы реализуете методы расширения для данного типа, помните следующее:

• Метод расширения никогда не будет вызван, если он имеет ту же сигнатуру, что и метод, определенный в типе.
• Методы расширения вводятся в область действия на уровне пространства имен. Например, если у вас есть несколько статических классов, которые содержат методы расширения в одном именованном пространстве имен Extensions, все они будут перенесены в область действия using Extensions;директивой.

Подводя итог, можно сказать, что методы расширения предназначены для добавления методов экземпляра к определенному типу, даже если разработчики не могут сделать это напрямую. А поскольку методы экземпляра всегда будут переопределять методы расширения, если они есть (если они вызваны с использованием синтаксиса метода экземпляра), это следует делать только в том случае, если вы не можете напрямую добавить метод или расширить класс. *

Другими словами, метод расширения должен действовать точно так же, как и метод экземпляра, поскольку в конечном итоге он может быть создан методом экземпляра некоторым клиентом. И поскольку метод экземпляра должен выдавать, если объект, к которому он вызывается null, так же, как и метод расширения.

* В качестве дополнительного примечания, именно с такой ситуацией столкнулись дизайнеры LINQ: когда был выпущен C # 3.0, уже были миллионы клиентов, которые использовали System.Collections.IEnumerableи System.Collections.Generic.IEnumerable<T>в своих коллекциях, и в foreachциклах. Эти классы возвращаются IEnumeratorобъекты , которые были только два метода Currentи MoveNext, таким образом добавляя дополнительные необходимые методы , например, такие , как Count, Anyи т.д., будет нарушать эти миллионы клиентов. Таким образом, чтобы обеспечить эту функциональность (особенно потому, что она может быть реализована с точки зрения Currentи MoveNextс относительной простотой), они выпустили ее как методы расширения, которые можно применять к любым существующим в настоящее времяIEnumerableэкземпляр и может также быть реализован классами более эффективными способами. Если бы дизайнеры C # решили выпустить LINQ в первый же день, он был бы представлен как методы экземпляра IEnumerable, и они, вероятно, разработали бы какую-то систему для обеспечения реализаций интерфейса этих методов по умолчанию.

Я думаю, что существенным моментом здесь является то, что, возвращая false вместо того, чтобы выдавать исключение, вы запутываете информацию, которая может иметь отношение к будущим читателям / модификаторам вашего кода.

Если список может быть пустым, я бы предложил для этого отдельный логический путь, так как в противном случае кто-то в будущем может добавить некоторую основанную на списке логику (например, добавление) к else {} вашего if, что приведет к нежелательное исключение, что у них нет оснований прогнозировать.

Читаемость и удобство сопровождения превосходят «Я должен написать дополнительное условие» каждый раз.

Как правило, я пишу большую часть своего кода, предполагая, что вызывающая сторона отвечает за то, чтобы не передавать мне нулевые данные, в основном по причинам, изложенным в « Скажи нет пустому» (и другим подобным постам). Концепция нуля часто не совсем понятна, и поэтому желательно инициализировать ваши переменные заранее, насколько это практически возможно. Предполагая, что вы работаете с разумным API, в идеале вы никогда не должны возвращать нулевое значение, поэтому вам никогда не придется проверять нулевое значение. Смысл нуля, как утверждали другие ответы, - это убедиться, что у вас есть действующий объект (например, «сумка») для работы, прежде чем продолжить. Это не особенность Any, а особенность языкасам. Вы не можете выполнять большинство операций с нулевым объектом, потому что он не существует. Это как если бы я попросил вас доехать до магазина на моей машине, за исключением того, что у меня нет машины, поэтому у вас нет возможности использовать мою машину, чтобы доехать до магазина. Бессмысленно выполнять операцию над чем-то, что буквально не существует.

Существуют практические случаи использования нулевого значения, например, когда у вас буквально нет запрошенной информации (например, если я спросил вас, какого мне возраста, наиболее вероятный вариант ответа на этот вопрос - «Я не знаю»). ", что является нулевым значением). Однако в большинстве случаев вы должны хотя бы знать, инициализированы ли ваши переменные или нет. А если нет, то я бы порекомендовал вам ужесточить свой код. Самое первое, что я делаю в любой программе или функции, это инициализирую значение перед тем, как его использовать. Редко мне нужно проверять наличие нулевых значений, потому что я могу гарантировать, что мои переменные не равны нулю. Это хорошая привычка, и чем чаще вы не забываете инициализировать свои переменные, тем реже вам нужно проверять наличие нуля.