Чи нерозумно очікувати, що будь-який () * не * викине нульовий посилання на виняток?

При створенні методу розширення ви можете, звичайно, назвати його по 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і порожні еквівалентні, ви можете переконатися, що він ніколи не містить 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повністю усунути умови.

Я помиляюся, як клієнт цього коду, очікував, що, наприклад, ((int []) null). Any () повинен повернути помилкове?

Так, просто тому, що ти перебуваєш у C # і така поведінка чітко визначена та задокументована.

Якщо ви створювали власну бібліотеку або використовували іншу мову з різною культурою виключень, тоді було б розумніше розраховувати на помилкове.

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

Якщо повторні нульові перевірки вас дратують, ви можете створити свій власний метод розширення 'IsNullOrEmpty ()', щоб відобразити метод String за цим ім'ям і обернути як єдиний виклик, так і виклик .Any () в один виклик.

Інакше рішення, згадане @ 17 з 26 у коментарі під вашим запитанням, також коротше, ніж «стандартний» метод, і зрозуміло для всіх, хто знайомий з новим нульовим умовним синтаксисом.

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

Я помиляюся, як клієнт цього коду, очікував, що, наприклад, ((int []) null). Any () повинен повернути помилкове?

Якщо ви замислюєтесь над очікуванням, вам доведеться подумати про наміри.

null означає щось дуже відмінне від Enumerable.Empty<T>

Як згадується у відповіді Еріка Ейдта , різниця в значенні між nullі порожньою колекцією.

Давайте спочатку подивимось на те, як їх слід використовувати.

Книга Framework Design Guidelines: конвенції, ідіоми і шаблони для багаторазового використання .NET бібліотек, друге видання , написаного Microsoft архітекторів Кшиштоф Кваліна і Бред Абрамс стверджує наступні кращі практики:

X НЕ повертайте нульові значення з властивостей колекції або з методів повернення колекцій. Натомість поверніть порожню колекцію чи порожній масив.

Розглянемо ваш метод виклику, який в кінцевому підсумку отримує дані з бази даних: Якщо ви отримуєте порожній масив або Enumerable.Empty<T>це просто означає, що ваш вибірковий простір порожній, тобто ваш результат - порожній набір . nullОднак одержання в цьому контексті означатиме стан помилки .

У тому ж думці, що і в аналогії з картоплею Дена Вілсона , є сенс задавати питання щодо своїх даних, навіть якщо це порожній набір . Але це має набагато менший сенс, якщо немає набору .

Є багато відповідей, що пояснюють, чому nullі порожні різні, і достатньо думок, які намагаються пояснити обидва, чому до них слід ставитися по-різному чи ні. Однак ви запитуєте:

Я помиляюся, як клієнт цього коду, очікував, що, наприклад, ((int []) null). Any () повинен повернути помилкове?

Це цілком розумні очікування . Ви такі ж праві, як і хтось, хто виступає за поточну поведінку. Я погоджуюся з існуючою філософією впровадження, але рушійні фактори не тільки - ґрунтуються на міркуваннях поза контекстом.

Враховуючи, що 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. Це той самий метод, і він повинен узгоджуватися - можливо - майже з ВСЕМ іншим у рамках.
• Доступ до nullоб'єкта - це помилка програмування , фреймворк не повинен застосовувати нуль як магічне значення . Якщо ви використовуєте його таким чином, тоді ви несете відповідальність за це.
• Це впевнено , ти думаєш один спосіб, а я думаю інший. Рамки повинні бути максимально непідданими.
• Якщо у вас є особливий випадок, тоді ви повинні бути послідовними : вам доведеться приймати все більше і більш впевнених рішень щодо всіх інших методів розширення: якщо це Count()здається простим рішенням, Where()це не так. Про що Max()? Він кидає виняток для списку EMPTY, чи не повинен він кидати і для nullодного?

Те, що дизайнери бібліотеки робили перед LINQ, було ввести явні методи, коли nullце дійсне значення (наприклад String.IsNullOrEmpty()), то вони HAD повинні відповідати існуючій філософії дизайну . Це сказало, навіть якщо це досить тривіально написати, два способи EmptyIfNull()і EmptyOrNull()можуть бути корисними.

Джим повинен залишати картоплю в кожному пакетику. Інакше я збираюся його вбити.

У Джима є мішок з п'ятьма картоплями. Чи є .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, і вони, ймовірно, розробили б якусь систему, щоб забезпечити реалізацію цих методів інтерфейсом за замовчуванням.

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

Якщо можливо, що список є недійсним, я б запропонував окремий логічний шлях для цього, оскільки в іншому випадку в майбутньому хтось може додати якусь логіку, засновану на списку (наприклад, додавання), до іншого {} вашої, якщо це призведе до небажаний виняток, що вони не мали підстав передбачати.

Козирі для читабельності та ремонтопридатності "Я повинен писати додаткову умову" кожного разу.

Як правило, я пишу більшу частину свого коду, щоб вважати, що абонент несе відповідальність за те, що він не передає мені нульові дані, здебільшого з причин, викладених у " Скажіть" нулю (та інших подібних публікаціях). Поняття null часто недостатньо вивчене, і з цієї причини доцільно ініціалізувати свої змінні достроково, наскільки це практично. Якщо припустити, що ви працюєте з розумним API, то в ідеалі не слід ніколи повертати нульове значення, тому вам ніколи не доведеться перевіряти наявність нуля. Суть нуля, як заявили інші відповіді, полягає в тому, щоб переконатися, що у вас є дійсний об'єкт (наприклад, «сумка»), з яким потрібно працювати, перш ніж продовжувати. Це не особливість Any, а натомість особливість мовисебе. Ви не можете виконати більшість операцій з нульовим об'єктом, оскільки він не існує. Це так, якби я попросив вас заїхати до магазину в моїй машині, за винятком того, що я не є власником машини, тож у вас немає можливості використовувати мою машину, щоб їхати до магазину. Безглуздо виконувати операцію на тому, чого буквально не існує.

Є практичні випадки використання нуля, наприклад, коли ви буквально не маєте потрібної інформації (наприклад, якщо я запитав вас, який мій вік, найімовірніший вибір, з якого ви б відповіли на даний момент, це "я не знаю ", що таке нульове значення). Однак у більшості випадків вам слід принаймні знати, чи ваші змінні ініціалізовані чи ні. Якщо ви цього не зробите, то я б рекомендував вам посилити свій код. Найперше, що я роблю в будь-якій програмі чи функції, - це ініціалізувати значення перед тим, як використовувати його. Рідко мені потрібно перевірити наявність нульових значень, тому що я можу гарантувати, що мої змінні не є нульовими. Це добра звичка входити, і чим частіше ви пам’ятаєте про ініціалізацію змінних, тим рідше вам потрібно перевіряти на нуль.