输入在技术上有效但不满意时，异常与空结果集

我正在开发要公开发布的库。它包含用于对对象集进行操作的各种方法-生成，检查，分区并将这些集投影到新形式。如果相关，它是一个C＃类库，其中包含LINQ样式的扩展IEnumerable，将作为NuGet软件包发布。

该库中的某些方法可能会被赋予无法满足的输入参数。例如，在组合方法中，存在一种生成可以从m个项目的源集合构造的n个项目的所有集合的方法。例如，给定集合：

1，2，3，4，5

并要求2的组合将产生：

1，2
1，3
1，4
等...
5，3
5，4

现在，显然可以要求做一些无法完成的事情，例如给它提供3个项目的集合，然后要求4个项目的组合，同时设置说只能使用每个项目一次的选项。

在这种情况下，每个参数都是单独有效的：

• 源集合不为null，并且包含项
• 要求的组合大小为正非零整数
• 请求的模式（仅使用每个项目一次）是有效选择

但是，将这些参数的状态放在一起时会引起问题。

在这种情况下，您是否希望该方法引发异常（例如InvalidOperationException）或返回空集合？在我看来，任何一种都有效：

• 如果只允许每个项目使用一次，则不能从m个项目的集合（其中n> m个）中产生n个项目的组合，因此该操作被认为是不可能的。InvalidOperationException
• 当n> m时可以从m个项目中生成的大小为n的组合的集合为空集；无法产生任何组合。

空集的参数

我首先担心的是，当您处理大小可能未知的数据集时，异常会阻止惯用的LINQ样式方法链接。换句话说，您可能想要执行以下操作：

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

如果您的输入集大小可变，则此代码的行为是不可预测的。如果少于4个元素.CombinationsOf()时引发异常someInputSet，则此代码有时会在运行时失败，而无需进行一些预检查。在上面的示例中，此检查是微不足道的，但是如果您在较长的LINQ链中途调用它，则可能会变得乏味。如果它返回一个空集，result则将为空，您可能会很满意。

例外的论点

我的第二个担心是，返回一个空集可能会隐藏问题-如果您在LINQ链的中途调用此方法，并且它悄悄地返回一个空集，那么稍后可能会遇到问题，或者发现自己为空结果集，鉴于您肯定在输入集中有某些内容，这种情况的发生可能并不明显。

您会期望什么，您对此有何看法？

返回空集

我期望有一个空集，因为：

当我只能使用每个数字一次时，存在3个集合中的4个数字的0个组合

如有疑问，请问其他人。

您的示例函数在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。

用外行的话来说：

• 如果有错误，则应引发异常。这可能涉及分步执行操作，而不是在单个链接调用中进行操作，以便确切地知道错误发生的位置。
• 如果没有错误，但是结果集为空，则不引发异常，返回空集。空集是有效集。

我同意Ewan的回答，但想添加一个具体的理由。

您正在处理数学运算，因此坚持使用相同的数学定义可能是一个不错的建议。从数学的角度的数量ř一个的-Sets Ñ -set（即nCr的）的所有r被良好限定> N> = 0的零。因此，从数学的角度来看，返回空集将是预期的情况。

我发现一种确定是否使用异常的好方法，就是想象人们正在参与交易。

以获取文件内容为例：

1. 请获取文件“不存在.txt”的内容

   一种。“这里是内容：空字符集”

   b。“ Erm，有一个问题，该文件不存在。我不知道该怎么办！”

2. 请获取文件内容“存在但为空.txt”

   一种。“这里是内容：空字符集”

   b。“ Erm，有问题，该文件中没有任何内容。我不知道该怎么办！”

毫无疑问，有些人会不同意，但是对于大多数人来说，“ Erm，有问题”在文件不存在时有意义，而在文件为空时返回“空字符集”。

因此，将相同的方法应用于您的示例：

3. 请给我所有4件物品的所有组合 {1, 2, 3}

   一种。没有，这里是空的。

   b。有一个问题，我不知道该怎么办。

同样，如果将例如null作为一组商品提供，那么“有问题”将是有意义的，但是“上述为空”似乎是对上述要求的明智回应。

如果返回空值掩盖了问题（例如，文件丢失，a null），则通常应改用异常（除非您选择的语言支持option/maybe类型，否则它们有时更有意义）。否则，返回一个空值可能会简化成本，并且更符合最小惊讶原则。

因为它是针对通用库的，所以我的直觉是让最终用户选择。

就像我们已经拥有Parse()并TryParse()可以使用的一样，我们可以根据函数需要的输出选择使用哪个选项。与争论选择单一版本的函数相比，花费更少的时间编写和维护函数包装程序以引发异常。

您需要验证调用函数时提供的参数。实际上，您想知道如何处理无效的参数。多个参数相互依赖的事实并不能弥补您验证参数的事实。

因此，我会投票支持ArgumentException，该异常为用户提供了必要的信息以了解发生了什么问题。

例如，检查public static TSource ElementAt<TSource>(this IEnumerable<TSource>, Int32)Linq中的 功能。如果索引小于0或大于或等于source中的元素数，则抛出ArgumentOutOfRangeException。因此，就调用方提供的可枚举而言，对索引进行了验证。

您应该执行以下操作之一（尽管会不断出现基本问题，例如组合数为负）：

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)

有两种方法可以确定是否没有明显的答案：

• 编写代码时首先选择一个选项，然后再选择另一个。考虑哪一个在实践中最有效。

• 添加“ strict”布尔参数以指示是否要严格验证参数。例如，Java SimpleDateFormat有一种setLenient方法可以尝试解析与格式不完全匹配的输入。当然，您必须决定默认值是什么。

根据您自己的分析，返回空集似乎很正确-您甚至已经将其标识为某些用户可能真正想要的东西，并且没有陷入禁止使用某些东西的陷阱，因为您无法想象用户曾经想要使用它那样。

如果您确实感觉到某些用户可能想强制非空返回，请给他们一种要求该行为的方法，而不是强加给所有人。例如，您可能会：

• 使其成为对用户执行操作的任何对象的配置选项。
• 将其设置为标志，用户可以选择将其传递给该函数。
• 提供AssertNonempty他们可以放入连锁店的支票。
• 做两个函数，一个断言非空，另一个不断言。

这实际上取决于您的用户期望获得什么。对于（某种程度上不相关的）示例，如果您的代码执行除法运算，则可能抛出异常或返回，Inf或者NaN被零除。然而，对与错都不是：

• 如果您返回InfPython库，人们会因隐藏错误而袭击您
• 如果您在Matlab库中引发错误，人们会因无法处理缺少值的数据而向您发起攻击

在您的情况下，我会选择对于最终用户来说最不令人惊讶的解决方案。由于您正在开发处理集合的库，因此，空集合似乎是用户希望处理的事情，因此返回它听起来很明智。但是我可能会弄错了：您对上下文的理解比这里的其他任何人都更好，因此，如果您希望用户依赖始终不为空的集合，则应立即抛出异常。

允许用户选择的解决方案（例如添加“ strict”参数）不是确定的，因为它们用新的等效问题替换了原始问题：“哪个值strict应为默认值？”

在数学中，通常的概念是：在集合中选择元素时，您找不到任何元素，因此会得到一个空集。当然，如果您采用这种方式，则必须与数学保持一致：

通用设置规则：

• Set.Foreach（谓词）; //对于空集始终返回true
• Set.Exists（谓词）; //对于空集总是返回false

您的问题非常微妙：

• 可能是函数的输入必须遵守合同：在这种情况下，任何无效的输入都应引发异常，就是这样，函数无法在常规参数下工作。

• 函数的输入可能必须完全像set一样，因此应该能够返回一个空set。

现在，如果我在您的位置，我将采用“设置”方式，但带有一个较大的“ BUT”。

假设您有一个集合，“按假设”应该只有女学生：

class FemaleClass{

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

现在，您的收藏不再是“纯粹的收藏”，因为您已经有了合同，因此应该例外地执行合同。

当以纯方式使用“集合”函数时，如果集合为空，则不应抛出异常，但是如果集合不再是“纯集合”，则应在适当的地方抛出异常。

您应该始终做更自然，更一致的事情：对我而言，一套应该坚持一套规则，而非一套东西应该具有正确的思维规则。

在您的情况下，这样做似乎是一个好主意：

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可以告诉我们更多关于它的领域的信息，那么也许我们可以找到真正需要例外的地方（如果完全有可能，这个问题根本不需要任何例外。