Чи слід приймати порожні колекції у своїх методах, які повторюють їх?

У мене є метод, коли вся логіка виконується всередині циклу foreach, який переходить через параметр методу:

public IEnumerable<TransformedNode> TransformNodes(IEnumerable<Node> nodes)
{
    foreach(var node in nodes)
    {
        // yadda yadda yadda
        yield return transformedNode;
    }
}

У цьому випадку надсилання порожньої колекції призводить до порожньої колекції, але мені цікаво, чи це нерозумно.

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

Чи варто вловлювати цю поведінку і кидати для неї виняток, або найкраще повернути порожню колекцію?

Корисні методи не повинні кидатися на порожні колекції. Ваші клієнти API ненавиджу вас за це.

Колекція може бути порожньою; концептуально набагато складніше працювати з "колекцією, що не повинна бути порожньою".

Трансформація порожньої колекції має очевидний результат: порожня колекція. (Ви навіть можете зберегти сміття, повернувши сам параметр.)

Існує багато обставин, коли модуль підтримує списки речей, які можуть бути, а можуть і не бути заповнені чимось. Необхідність перевіряти порожнечу перед кожним закликом transformдратує і має потенціал перетворити простий, елегантний алгоритм у некрасивий безлад.

Корисні методи завжди повинні прагнути бути ліберальними у своїх вкладах та консервативними у своїх результатах.

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

Я бачу два важливі питання, які визначають відповідь на це:

1. Чи може ваша функція повернути щось змістовне та логічне, коли пройде пусту колекцію (включаючи нульову )?
2. Який загальний стиль програмування в цій програмі / бібліотеці / команді? (Конкретніше, як у вас FP?)

1. Змістовне повернення

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

• Підраховує кількість елементів у колекції, повертаючи 0. Це було просто.
• Пошук елементів, які відповідають певним критеріям, повертає порожню колекцію. Будь ласка, нічого не кидайте. У абонента може бути величезна колекція колекцій, частина яких порожня, а деякі ні. Абонент бажає будь-яких відповідних елементів у будь-якій колекції. Винятки лише ускладнюють життя абонента.
• Шукає найбільший / найменший / найкращий за критеріями у списку. На жаль Залежно від питання про стиль, ви можете кинути тут виняток або повернути нуль . Я ненавиджу null (дуже людина FP), але це, мабуть, важливіше, і це дозволяє вам залишати винятки для несподіваних помилок у власному коді. Якщо абонент не перевіряє нуль, все одно вийде досить чітке виключення. Але це ви залишаєте їм.
• Запитує n-й елемент колекції або перший / останній n елементів. Це найкращий випадок для винятку і той, який найменш вірогідно може викликати плутанину та труднощі для абонента. Справа все ще може бути зведена на нуль, якщо ви та ваша команда звикли перевірити це з усіх причин, наведених у попередньому пункті, але це найбільш вірний випадок, поки викидаєте виняток DudeYou Know YouShouldCheckTheSizeFirst . Якщо ваш стиль є більш функціональним, то будь-що скасуйте чи прочитайте відповідь на мій стиль .

Загалом, моя упередженість ПП говорить мені "повернути щось значуще", і нульове значення може мати в цьому випадку значення.

2. Стиль

Чи корисний ваш загальний код (або код проекту чи код команди) функціональному стилю? Якщо ні, винятки будуть очікуватися та їх вирішувати. Якщо так, то розгляньте можливість повернення типу опції . З типом опції ви або повертаєте змістовну відповідь, або Нічого / Нічого . У моєму третьому прикладі зверху Ніщо не буде гарною відповіддю у стилі FP. Факт, що функція повертає сигнал вибору Option явно абоненту, ніж змістовна відповідь, може виявитися неможливим і що абонент повинен бути готовий з цим впоратися. Я відчуваю, що це надає абоненту більше варіантів (якщо ви простите каламбур).

F #, де все прохолодні .Net діти роблять такі речі , але C # робить підтримку цього стилю.

тл; д-р

Зберігайте винятки для несподіваних помилок у власному кодовому шляху, не цілком передбачуваному (та законному) введенні з чужого.

Як завжди, це залежить.

Чи має значення, що колекція порожня?
Більшість кодів поводження з колекцією, ймовірно, сказав би "ні"; у колекції може бути будь-яка кількість предметів, включаючи нуль.

Тепер, якщо у вас є якась колекція, де "недійсно" не мати в ній предметів, то це нова вимога, і ви повинні вирішити, що з цим робити.

Займіть деяку логіку тестування у світі баз даних: тест на нульові елементи, один предмет та два елементи. Це забезпечує найважливіші випадки (вимивання будь-яких погано сформованих внутрішніх або декартових умов приєднання).

Що стосується гарного дизайну, прийміть якомога більше варіацій ваших внесків, як це практично або можливо. Винятки слід викидати лише тоді, коли (подається неприйнятний вхід АБО трапляються несподівані помилки під час обробки) І програма не може продовжуватись передбачуваним чином .

У цьому випадку слід очікувати, що пуста колекція буде представлена, і ваш код повинен обробляти її (що вона вже робить). Було б порушення всього доброго, якби ваш код тут кинув виняток. Це було б подібним до множення 0 на 0 в математиці. Це зайве, але абсолютно необхідне, щоб він працював так, як це робиться.

Тепер перейдемо до аргументу нульового збору. У цьому випадку нульова колекція є помилкою програмування: програміст забув призначити змінну. Це випадок, коли викид може бути викинутий, тому що ви не зможете осмислено обробити це у висновку, а спроба зробити це призведе до несподіваної поведінки. Це було б подібне до ділення на нуль у математиці - це абсолютно безглуздо.

Правильне рішення набагато важче зрозуміти, коли ти просто дивишся на свою функцію ізольовано. Розгляньте свою функцію як частину більшої проблеми . Одне можливе рішення цього прикладу виглядає приблизно так (у Scala):

input.split("\\D")
.filterNot (_.isEmpty)
.map (_.toInt)
.filter (x => x >= 1000 && x <= 9999)

Спочатку ви розділите рядок на нецифрові цифри, відфільтруйте порожні рядки, перетворіть рядки в цілі числа, потім фільтруйте, щоб зберегти лише чотиризначні числа. Ваша функція може бути map (_.toInt)в роботі.

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

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

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

1) Метод повинен кидати виняток, коли він не може продовжуватись: або не в змозі виконати призначене завдання, або повернути відповідне значення.

2) Метод повинен зафіксувати виняток, коли він може продовжуватись, незважаючи на збій.

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

Повертає чи порожню колекцію чи нуль, трохи складніше, але не так багато: якщо можливо, слід уникати зведених колекцій. Мета колекції, що зводить нанівець, полягала б у тому, щоб вказати (як у SQL), що у вас немає такої інформації - наприклад, зібрання дітей може бути нульовим, якщо ви не знаєте, чи є хтось, але у вас немає знайте, що вони цього не роблять. Але якщо це важливо з якихось причин, напевно, варто відслідковувати додаткову змінну.

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

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

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

Давайте відступимо та скористаємось іншим прикладом, який обчислює середнє арифметичне масиву значень.

Якщо вхідний масив порожній (або нульовий), чи можете ви обгрунтовано виконати запит абонента? Ні. Які варіанти? Ну, ви могли:

• подати / повернути / кинути помилку. використовуючи умову вашої кодової бази для цього класу помилок.
• документа, що таке значення, як нуль, буде повернуто
• документ про повернення призначеного недійсного значення (наприклад, NaN)
• документ, що магічне значення буде повернуто (наприклад, min або max для типу або якесь сподіваюче орієнтовне значення)
• оголосити результат не визначеним
• оголосити дію не визначеною
• тощо.

Я кажу, дайте їм помилку, якщо вони дали вам недійсний вклад і запит не може бути виконаний. Я маю на увазі сильну помилку з першого дня, щоб вони зрозуміли вимоги вашої програми. Зрештою, ваша функція не в змозі відповісти. Якщо операція не змогла (наприклад, скопіювати файл), то ваш API повинен надати їм помилку, з якою вони можуть зіткнутися.

Таким чином, це може визначити, як ваша бібліотека обробляє помилкові запити та запити, які можуть не працювати.

Дуже важливо, щоб ваш код був послідовним у тому, як він обробляє ці класи помилок.

Наступна категорія - визначити, як ваша бібліотека обробляє запити дурниць. Повертаючись до прикладу подібного Вашим - давайте використовувати функцію , яка визначає , чи існує файл в дорозі: bool FileExistsAtPath(String). Якщо клієнт передає порожній рядок, як ви впораєтесь із цим сценарієм? Як щодо порожнього чи нульового масиву, переданого void SaveDocuments(Array<Document>)? Виберіть свою бібліотеку / базу коду та будьте послідовними. Мені трапляється вважати ці випадки помилками і забороняю клієнтам робити безглузді запити, позначаючи їх як помилки (через твердження). Деякі люди будуть сильно протистояти цій ідеї / дії. Я вважаю це виявлення помилок дуже корисним. Це дуже добре для розміщення питань у програмах - з хорошою локалізацією до програми, яка порушує правопорушення. Програми набагато чіткіші та правильніші (враховуйте еволюцію вашої кодової бази) і не записуйте цикли в межах функцій, які нічого не роблять. Таким чином, код менший / чистіший, і чеки, як правило, висуваються на місця, де може бути введена проблема.

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