我应该在遍历它们的方法中接受空集合吗？

我有一个方法，其中所有逻辑都在foreach循环内执行，该循环遍历该方法的参数：

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

在这种情况下，发送一个空集合会导致一个空集合，但是我想知道这是否不明智。

我的逻辑是，如果有人正在调用此方法，那么他们打算传入数据，并且只会在错误的情况下将空集合传递给我的方法。

我应该捕获此行为并抛出异常，还是返回空集合的最佳实践？

实用程序方法不应抛出空集合。您的API客户端会讨厌您。

集合可以为空；从概念上讲，“一定不能为空的集合”是一件更加困难的事情。

转换一个空集合有一个明显的结果：空集合。（您甚至可以通过返回参数本身来节省一些垃圾。）

在许多情况下，模块会维护可能已经填充或可能尚未填充的东西的列表。在每次调用之前都必须检查是否为空，这transform很烦人，并且有可能将简单，优雅的算法变成丑陋的混乱。

效用方法应始终努力使其输入自由，并在输出中保持保守。

由于所有这些原因，看在上帝的份上，正确处理空集合。没有什么比帮助程序模块更令人生气的了，该模块认为它比您更了解自己想要的东西。

我看到两个重要的问题，这些问题决定了答案：

1. 传递空集合（包括null）时，您的函数能否返回有意义且合乎逻辑的内容？
2. 该应用程序/库/团队中的一般编程风格是什么？（具体地说，您是FP吗？）

1.有意义的回报

本质上，如果您可以返回有意义的内容，则不要抛出异常。让调用者处理结果。所以如果你的功能...

• 计算集合中的元素数，返回0。这很容易。
• 搜索与特定条件匹配的元素，返回一个空集合。请不要扔任何东西。调用方可能有大量的集合，其中有些是空的，有些不是空的。调用方需要任何集合中的任何匹配元素。例外只会使呼叫者的生活更加艰难。
• 正在寻找列表中最大/最小/最适合的标准。哎呀。根据样式问题，您可以在此处引发异常，也可以返回null。我讨厌null（很多FP人员），但是在这里它可能更有意义，它可以让您为自己代码中的意外错误保留异常。如果呼叫者不检查null，无论如何都会产生一个相当明确的异常。但是，您将其留给他们。
• 询问集合中的第n个项目或前/后n个项目。这是发生异常的最佳情况，也是最不可能给调用者造成混乱和困难的一种情况。如果您和您的团队习惯于出于上述原因给出的所有原因进行检查，那么仍然可以将null设置为空，但这是引发DudeYou Know YouShouldCheckTheSizeFirst异常的最有效的情况。如果您的样式更具实用性，请为null或继续阅读我的样式答案。

通常，我的FP偏向告诉我“返回有意义的东西”，在这种情况下，null可能具有有效的含义。

2.风格

您的通用代码（或项目代码或团队代码）是否偏爱功能样式？如果否，则将预期并处理异常。如果是，则考虑返回Option Type。对于选项类型，您将返回有意义的答案或None / Nothing。在上面的第三个示例中，没有什么是FP风格的好答案。该函数返回Option类型的事实可能无法明确地向调用者发出信号，而不是有意义的答案，因此应准备好调用者进行处理。我觉得这为呼叫者提供了更多选择（如果您会原谅双关语的话）。

F＃是所有很酷的.Net孩子做这样的事情，但C＃不 支持这种风格。

tl; dr

在您自己的代码路径中保留意外错误的异常，而不是别人的输入完全可预见（合法）。

与以往一样，这取决于。

集合为空是否重要？
大多数收集处理代码可能会说“否”。集合中可以包含任意数量的项目，包括零。

现在，如果您有某种类型的集合，其中“没有”项是“无效的”，那么这是一项新要求，您必须决定如何处理。

从数据库世界借用一些测试逻辑：测试零项，一项和两项。这可以满足最重要的情况（清除任何格式不正确的内部或笛卡尔联接条件）。

作为一个好的设计，要尽可能多地接受您输入的变化。异常应仅在（接受输入呈现或在处理意外的错误发生）被抛出，程序无法预测的方式继续作为一个结果。

在这种情况下，应该期望将显示一个空集合，并且您的代码需要处理它（它已经这样做了）。如果您的代码在此处引发异常，那么这将违反所有的好处。这类似于在数学中将0乘以0。它是多余的，但绝对必须按其工作方式进行。

现在，转到null集合参数。在这种情况下，空集合是编程错误：程序员忘记分配变量。在这种情况下，可能会引发异常，因为您无法有意义地将其处理为输出，并且尝试这样做会引入意外的行为。这类似于数学中的零除-完全没有意义。

当您单独查看功能时，很难找到正确的解决方案。将您的功能视为更大问题的一部分。该示例的一种可能解决方案如下所示（在Scala中）：

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

首先，将字符串按非数字拆分，过滤出空字符串，将字符串转换为整数，然后过滤以仅保留四位数。您的功能可能map (_.toInt)在管道中。

该代码非常简单，因为管道中的每个阶段都只处理一个空字符串或一个空集合。如果在开头放置一个空字符串，则在末尾会得到一个空列表。您不必null在每次通话后都停下来检查是否有异常。

当然，这是假定一个空的输出列表没有多个含义。如果需要区分由空输入引起的空输出和由转换本身引起的空输出，那将完全改变事情。

这个问题实际上是关于异常的。如果您以这种方式看待它，而忽略空集合作为实现细节，那么答案很简单：

1）方法无法继续执行时应抛出异常：要么无法执行指定的任务，要么返回适当的值。

2）尽管失败，方法仍然能够继续执行，则该方法应捕获异常。

因此，您的辅助方法不应是“有帮助的”并且抛出异常，除非它无法使用空集合来完成它的工作。让调用者确定结果是否可以处理。

无论返回空集合还是null，都会有些困难，但难度不大：如果可能，应避免可空集合。可为空的集合的目的是指示（如SQL中一样）您没有该信息-例如，如果您不知道某人是否有子项，则子集合可能为null。知道他们不知道。但是，如果由于某些原因这很重要，则可能值得添加一个额外的变量来对其进行跟踪。

该方法名为TransformNodes。在输入空集合的情况下，取回空集合是自然而直观的，并且具有完善的数学意义。

如果该方法被命名Max并设计为返回最大元素，那么自然会抛出NoSuchElementException一个空集合，因为最大的无意义在数学上是没有意义的。

如果该方法的名称被JoinSqlColumnNames设计为返回一个字符串，该字符串中的元素由逗号连接以用于SQL查询，则抛出IllegalArgumentException一个空集合是有意义的，因为如果调用者使用了该方法，最终还是会遇到SQL错误直接在SQL查询中查询字符串，而无需进一步检查，他实际上应该检查空集合，而不是检查返回的空字符串。

让我们退后一步，使用另一个示例，该示例计算值数组的算术平均值。

如果输入数组为空（或null），则可以合理地满足调用者的请求吗？不，您有什么选择？好吧，您可以：

• 存在/返回/抛出错误。使用您的代码库惯例来处理此类错误。
• 文档将返回诸如零的值
• 文档，将返回指定的无效值（例如，NaN）
• 记录将返回魔术值（例如，类型的最小值或最大值或一些希望指示的值）
• 声明结果未指定
• 声明动作未定义
• 等等

我说如果他们给您无效的输入并且请求无法完成，请给他们错误。我的意思是从第一天开始就出现了严重错误，因此他们了解您的程序要求。毕竟，您的功能无法响应。如果操作可能失败（例如，复制文件），那么您的API应该给他们一个可以处理的错误。

这样可以定义您的库如何处理格式错误的请求以及可能失败的请求。

对于您的代码来说，在处理这些错误类别方面保持一致非常重要。

下一个类别是决定您的图书馆如何处理废话请求。回到与您类似的示例-让我们使用一个函数来确定文件是否存在于路径：bool FileExistsAtPath(String)。如果客户端传递一个空字符串，您如何处理这种情况？传递给空数组或空数组如何void SaveDocuments(Array<Document>)？确定您的库/代码库，并保持一致。我碰巧考虑了这些案例错误，并通过将它们标记为错误（通过断言）来禁止客户端发出无意义的请求。有些人会坚决抵制该想法/行动。我发现此错误检测非常有帮助。这对于在程序中查找问题非常有用-定位到有问题的程序的适当位置。程序更加清晰和正确（考虑代码库的演变），并且不会在无能为力的函数中燃烧循环。这样，代码的大小就会变得更小/更干净，并且检查通常会推到可能引入问题的位置。

根据经验，标准函数应该能够接受最广泛的输入列表并给出反馈。在许多示例中，程序员以设计人员未计划的方式使用函数，因此我相信函数应该不仅能够接受空集合，而且还能够接受各种输入类型，并且能够优雅地返回反馈，即使它是对输入执行的任何操作的错误对象……