Виняток проти порожнього результату встановлюється, коли входи технічно достовірні, але незадовільні

Я розробляю бібліотеку, призначену для публічного випуску. Він містить різні методи роботи з наборами об'єктів - генерування, перевірка, розділення та проектування наборів у нові форми. У випадку, якщо це доречно, це бібліотека класів C #, що містить розширення у стилі LINQ IEnumerable, випускається як пакет NuGet.

Деяким із методів цієї бібліотеки можуть бути задані незадовільні вхідні параметри. Наприклад, у комбінаторних методах є метод для генерації всіх наборів з n елементів, які можна побудувати з вихідного набору m елементів. Наприклад, з урахуванням набору:

1, 2, 3, 4, 5

а запитання про комбінації 2 призведе до:

1, 2
1, 3
1, 4
тощо ...
5, 3
5, 4

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

У цьому сценарії кожен параметр діє індивідуально :

• Колекція джерела не є нульовою і містить елементи
• Запитаний розмір комбінацій - це додатне ненулеве ціле число
• Запитаний режим (використовуйте кожен елемент лише один раз) є правильним вибором

Однак стан параметрів при їх узятті створює проблеми.

У цьому сценарії ви очікуєте, що метод викине виняток (наприклад InvalidOperationException) або поверне порожню колекцію? Для мене це видається дійсним:

• Ви не можете створити комбінації n елементів із набору m елементів, де n> m, якщо вам дозволяється використовувати кожен елемент лише один раз, тому цю операцію можна вважати неможливою InvalidOperationException.
• Набір комбінацій розміру n, які можуть бути створені з m елементів, коли n> m - порожній набір; ніяких комбінацій не може бути вироблено.

Аргумент для порожнього набору

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

var result = someInputSet
    .CombinationsOf(4, CombinationsGenerationMode.Distinct)
    .Select(combo => /* do some operation to a combination */)
    .ToList();

Якщо ваш набір змінних розмірів, поведінка цього коду непередбачувана. Якщо .CombinationsOf()викид має виняток, коли в someInputSetньому менше 4 елементів, то цей код іноді виходить з ладу під час виконання без попередньої перевірки. У наведеному вище прикладі ця перевірка є тривіальною, але якщо ви називаєте її на півдорозі довшою ланцюжком LINQ, це може стати втомливим. Якщо він поверне порожній набір, то resultвін буде порожнім, чим ви можете бути цілком задоволені.

Аргумент на виняток

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

Що б ви очікували, і який ваш аргумент для цього?

Поверніть порожній набір

Я б очікував порожнього набору, оскільки:

З набору 3 є 0 комбінацій 4 чисел, коли я можу використовувати кожне число лише один раз

Якщо сумніваєтесь, запитайте когось іншого.

Ваша прикладна функція має дуже подібну функцію в Python : itertools.combinations. Подивимося, як це працює:

>>> import itertools
>>> input = [1, 2, 3, 4, 5]
>>> list(itertools.combinations(input, 2))
[(1, 2), (1, 3), (1, 4), (1, 5), (2, 3), (2, 4), (2, 5), (3, 4), (3, 5), (4, 5)]
>>> list(itertools.combinations(input, 5))
[(1, 2, 3, 4, 5)]
>>> list(itertools.combinations(input, 6))
[]

І мені це чудово чудово. Я очікував результату, який я міг би повторити, і отримав такий.

Але, очевидно, якби ти запитав щось дурне:

>>> list(itertools.combinations(input, -1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: r must be non-negative

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

Як сказав @Bakuriu в коментарях, це також те саме, що і для SQLзапиту SELECT <columns> FROM <table> WHERE <conditions>. Поки <columns>, <table>, <conditions>добре сформовані і формуються посилання на існуючі імена, ви можете створити набір умов , що виключають одна одну. Отриманий запит просто не дасть рядків замість того, щоб викидати an InvalidConditionsError.

Простіше кажучи:

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

Я згоден з відповіддю Юана, але хочу додати конкретні міркування.

Ви маєте справу з математичними операціями, тому може бути корисною порадою дотримуватися однакових математичних визначень. З математичної точки зору кількість r- наборів n- набору (тобто nCr ) добре визначена для всіх r> n> = 0. Воно дорівнює нулю. Тому повернення порожнього набору було б очікуваним випадком з математичної точки зору.

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

Візьмемо приклад вмісту файлу:

1. Будь ласка, донесіть до мене вміст файлу "не існує.txt"

   а. "Ось вміст: порожня колекція символів"

   б. "Ем, є проблема, що файл не існує. Я не знаю, що робити!"

2. Будь ласка, донесіть до мене вміст файлу, "існує, але порожній.txt"

   а. "Ось вміст: порожня колекція символів"

   б. "Ем, є проблема. У цьому файлі нічого немає. Я не знаю, що робити!"

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

Тож застосовуючи такий же підхід до вашого прикладу:

3. Будь ласка, дайте мені всі комбінації 4 предметів для {1, 2, 3}

   а. Немає таких, ось порожній набір.

   б. Є проблема, я не знаю, що робити.

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

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

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

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

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

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

Як приклад, перевірте public static TSource ElementAt<TSource>(this IEnumerable<TSource>, Int32)функцію в Linq. Який кидає ArgumentOutOfRangeException, якщо індекс менше 0 або більший або дорівнює кількості елементів у джерелі. Таким чином, індекс підтверджується щодо кількості, наданої абонентом.

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

1. Забезпечте дві реалізації: одна, яка повертає порожній набір, коли входи разом є безглуздими, і одна, яка кидає. Спробуйте зателефонувати їм CombinationsOfі CombinationsOfWithInputCheck. Або все, що вам подобається. Ви можете змінити це, щоб перевіркою введення було коротше ім'я та список CombinationsOfAllowInconsistentParameters.

2. Для методів Linq поверніть порожнє IEnumerableв точне приміщення, яке ви окреслили. Потім додайте ці методи Linq до своєї бібліотеки:

   public static class EnumerableExtensions {
      public static IEnumerable<T> ThrowIfEmpty<T>(this IEnumerable<T> input) {
         return input.IfEmpty<T>(() => {
            throw new InvalidOperationException("An enumerable was unexpectedly empty");
         });
      }
   
      public static IEnumerable<T> IfEmpty<T>(
         this IEnumerable<T> input,
         Action callbackIfEmpty
      ) {
         var enumerator = input.GetEnumerator();
         if (!enumerator.MoveNext()) {
            // Safe because if this throws, we'll never run the return statement below
            callbackIfEmpty();
         }
         return EnumeratePrimedEnumerator(enumerator);
      }
   
      private static IEnumerable<T> EnumeratePrimedEnumerator<T>(
         IEnumerator<T> primedEnumerator
      ) {
         yield return primedEnumerator.Current;
         while (primedEnumerator.MoveNext()) {
            yield return primedEnumerator.Current;
         }
      }
   }

   Нарешті, використовуйте це так:

   var result = someInputSet
      .CombinationsOf(4, CombinationsGenerationMode.Distinct)
      .ThrowIfEmpty()
      .Select(combo => /* do some operation to a combination */)
      .ToList();

   або так:

   var result = someInputSet
      .CombinationsOf(4, CombinationsGenerationMode.Distinct)
      .IfEmpty(() => _log.Warning(
         $@"Unexpectedly received no results when creating combinations for {
            nameof(someInputSet)}"
      ))
      .Select(combo => /* do some operation to a combination */)
      .ToList();

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

   Однак зауважте, що, звичайно, він повинен перерахувати хоча б перший пункт, щоб визначити, чи є якісь елементи. Це потенційний недолік , який я думаю , що в основному знижується за рахунок того , що будь-які майбутні глядачі можуть досить легко міркувати про те , що ThrowIfEmptyметод повинен перерахувати принаймні один елемент, тому слід НЕ здивуєш це робити. Але ти ніколи не знаєш. Ви можете зробити це більш явним ThrowIfEmptyByEnumeratingAndReEmittingFirstItem. Але це здається гігантським зайвим.

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

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

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

.CombinationsOf(4, CombinationsGenerationMode.Distinct, Options.AllowEmptySets)

Є два підходи, щоб вирішити, чи немає явної відповіді:

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

• Додайте "суворий" булевий параметр, щоб вказати, хочете ви, щоб параметри були суворо перевірені чи ні. Наприклад, у Java SimpleDateFormatє setLenientметод спроби розбору входів, які не повністю відповідають формату. Звичайно, вам доведеться вирішити, що таке за замовчуванням.

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

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

• Зробіть його параметром конфігурації для будь-якого об’єкта, що виконує дію для користувача.
• Зробити це прапором, який користувач може додатково перейти у функцію.
• Надайте AssertNonemptyчек, який вони можуть поставити у свої ланцюги.
• Зробіть дві функції, таку, яка стверджує, що не порожня, та та, що не відповідає.

Це дійсно залежить від того, що очікують отримати ваші користувачі. На прикладі (дещо неспорідненого) прикладу, якщо ваш код виконує поділ, ви можете або викинути виняток, або повернутись, Infабо NaNподілити на нуль. Однак це ні правильно, ні неправильно:

• якщо ви повернетесь Infдо бібліотеки Python, люди нападуть на вас за приховування помилок
• якщо ви виявите помилку в бібліотеці Matlab, люди нападуть на вас за те, що не обробляли дані з відсутніми значеннями

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

Рішення, які дозволяють користувачеві вибрати (наприклад, додавання "строгого" параметра), не є остаточним, оскільки вони замінюють вихідний питання новим еквівалентним: "Яке значення strictмає бути за замовчуванням?"

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

Загальні правила встановлення:

• Set.Foreach (присудок); // завжди повертає true для порожніх наборів
• Set.Exists (присудок); // завжди повертає false для порожніх наборів

Ваше запитання дуже тонке:

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

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

Тепер, якби я був у вас, я б пішов шляхом "Встановити", але з великим "АЛЕ".

Припустимо, у вас є колекція, яка "за допомогою гіпотезу" повинна мати лише студенток:

class FemaleClass{

    FemaleStudent GetAnyFemale(){
        var femaleSet= mySet.Select( x=> x.IsFemale());
        if(femaleSet.IsEmpty())
            throw new Exception("No female students");
        else
            return femaleSet.Any();
    }
}

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

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

Ви завжди повинні робити те, що вважається більш природним і послідовним: для мене набір повинен дотримуватися встановлених правил, тоді як речі, які не є наборами, повинні мати свої правильно продумані правила.

У вашому випадку здається, що це зробити добре:

List SomeMethod( Set someInputSet){
    var result = someInputSet
        .CombinationsOf(4, CombinationsGenerationMode.Distinct)
        .Select(combo => /* do some operation to a combination */)
        .ToList();

    // the only information here is that set is empty => there are no combinations

    // BEWARE! if 0 here it may be invalid input, but also a empty set
    if(result.Count == 0)  //Add: "&&someInputSet.NotEmpty()"

    // we go a step further, our API require combinations, so
    // this method cannot satisfy the API request, then we throw.
         throw new Exception("you requsted impossible combinations");

    return result;
}

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

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