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

Я занимаюсь разработкой библиотеки, предназначенной для публичного выпуска. Он содержит различные методы для работы с наборами объектов - генерация, проверка, разбиение и проецирование наборов в новые формы. Если это уместно, это библиотека классов 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 и он спокойно возвращает пустой набор, то вы можете столкнуться с проблемами через несколько шагов или оказаться с пустым набор результатов, и может не быть очевидным, как это произошло, учитывая, что у вас определенно было что-то во входном наборе.

Чего бы вы ожидали, и каков ваш аргумент для этого?

Вернуть пустой набор

Я ожидал бы пустой набор, потому что:

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

Если есть сомнения, спросите кого-нибудь еще.

Ваш пример функция имеет очень похожие один в 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>хорошо сформированы и формируются ссылки на существующие имена, вы можете создать набор условий , которые исключают друг друга. Результирующий запрос просто не даст никаких строк вместо броска InvalidConditionsError.

С точки зрения непрофессионала:

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

Я согласен с ответом Эвана, но хочу добавить конкретную аргументацию.

Вы имеете дело с математическими операциями, поэтому может быть хорошим советом придерживаться тех же математических определений. С математической точки зрения число r- множеств n- множества (т. Е. NCr ) хорошо определено для всех r> n> = 0. Оно равно нулю. Поэтому возвращение пустого набора было бы ожидаемым случаем с математической точки зрения.

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

Взяв в качестве примера извлечение содержимого файла:

1. Пожалуйста, принесите мне содержимое файла, "не существует. Текст"

   а. «Вот содержимое: пустая коллекция символов»

   б. «Хм, проблема в том, что этот файл не существует. Я не знаю, что делать!»

2. Пожалуйста, извлеките мне содержимое файла, "существует, но является пустым.txt"

   а. «Вот содержимое: пустая коллекция символов»

   б. «Хм, есть проблема, в этом файле ничего нет. Я не знаю, что делать!»

Без сомнения, некоторые не согласятся, но для большинства людей «Эрм, есть проблема» имеет смысл, когда файл не существует, и возвращает «пустую коллекцию символов», когда файл пуст.

Таким образом, применяя тот же подход к вашему примеру:

3. Пожалуйста, дайте мне все комбинации из 4 предметов для {1, 2, 3}

   а. Их нет, вот пустой набор.

   б. Есть проблема, я не знаю, что делать.

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

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

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

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

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

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

В качестве примера, проверьте 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();

   Обратите внимание, что закрытый метод, отличный от публичного, необходим для того, чтобы поведение throw или action происходило при создании цепочки 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;
}

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

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