返回无效的不良设计吗？[关闭]

我听到一些声音说，从方法中检查返回的空值是错误的设计。我想听到一些原因。

伪代码：

variable x = object.method()
if (x is null) do something

不返回null的基本原理是您不必检查它，因此您的代码无需根据返回值遵循其他路径。您可能想查看Null对象模式，它提供了有关此信息的更多信息。

例如，如果我要用Java定义一个返回Collection的方法，那么我通常希望返回一个空collection（即Collections.emptyList()）而不是null，因为这意味着我的客户端代码更干净；例如

Collection<? extends Item> c = getItems(); // Will never return null.

for (Item item : c) { // Will not enter the loop if c is empty.
  // Process item.
}

...比以下更清洁：

Collection<? extends Item> c = getItems(); // Could potentially return null.

// Two possible code paths now so harder to test.
if (c != null) {
  for (Item item : c) {
    // Process item.
  }
}

这就是原因。

他在Robert Martin的Clean Code中写道，如果可以改为返回空数组，则返回null是错误的设计。由于预期结果是一个数组，为什么不呢？它使您无需任何额外条件即可遍历结果。如果是整数，则可能为0，如果是哈希，则为空哈希。等等

前提是不要强迫调用代码立即处理问题。调用代码可能不想与它们有关。这就是为什么在许多情况下，例外比零更好。

返回null的好用法：

• 如果null是有效的函数结果，例如：FindFirstObjectThatNeedsProcessing（）可以返回null（如果找不到），则调用者应进行相应检查。

不良用法：尝试替换或隐藏特殊情况，例如：

• catch（...）并返回null
• API依赖项初始化失败
• 磁盘空间不足
• 输入参数无效（编程错误，输入必须由调用方清除）
• 等等

在这些情况下，抛出异常就足够了，因为：

• 返回值为空不会提供有意义的错误信息
• 直接呼叫者很可能无法处理错误情况
• 无法保证调用方检查的是空结果

但是，不应将异常用于处理正常的程序操作条件，例如：

• 无效的用户名/密码（或任何用户提供的输入）
• 中断循环或非本地异常

是的，在面向对象的世界中，返回NULL是一个糟糕的设计。简而言之，使用NULL会导致：

• 临时错误处理（而不是异常）
• 模棱两可的语义
• 缓慢而不是快速失败
• 计算机思维而非对象思维
• 可变和不完整的对象

查看此博客文章以获取详细说明：http : //www.yegor256.com/2014/05/13/why-null-is-bad.html。在我的《优雅的物体》第4.1节中有更多内容。

谁说这是不好的设计？

检查空值是一种惯例，甚至鼓励这样做，否则，到处都有NullReferenceExceptions的风险。与不需要时抛出异常相比，优雅地处理错误要好于抛出异常。

根据您到目前为止的发言，我认为没有足够的信息。

从CreateWidget（）方法返回null似乎很糟糕。

从FindFooInBar（）方法返回null似乎很好。

它的发明者说这是十亿美元的错误！

这取决于您使用的语言。如果您使用的是C＃之类的语言，表示缺少值的惯用方式是返回null，那么如果没有值，则返回null是一个不错的设计。另外，在像Haskell这样的语言中，在这种情况下习惯使用Maybe monad的语言，那么返回null将是一个糟糕的设计（即使可能的话）。

如果您阅读了所有答案，则可以很清楚地看到此问题的答案取决于方法的类型。

首先，当发生异常情况（IO问题等）时，逻辑上会引发异常。当确实有什么例外的时候，可能是针对其他主题的事情。

只要期望一种方法可能没有结果，就会有两类：

• 如果有可能返回中性值，请这样做。
  空的枚举，字符串等都是很好的例子
• 如果不存在这样的中性值，则应返回null。
  如前所述，假定该方法可能没有结果，因此它不是例外，因此不应引发异常。中性值是不可能的（例如：0并不是特别中性的结果，具体取决于程序）

直到我们有一种正式的方法来表示一个函数可以或不能返回null为止，我尝试使用一个命名约定来表示它。
就像您对预期会失败的方法具有Try Something（）约定一样，当方法返回中性结果而不是null时，我经常将我的方法命名为Safe Something（）。

我还不太满意这个名字，但是无法提出更好的建议。所以我现在就开始讨论。

我在这个领域有个惯例对我很有帮助

对于单项查询：

• Create...返回一个新实例，或者抛出
• Get...返回预期的现有实例，或抛出
• GetOrCreate...返回一个现有实例，如果不存在则返回一个新实例，否则抛出
• Find...返回现有实例（如果存在），或者null

对于集合查询：

• Get... 总是返回一个集合，如果没有找到匹配的[1]项，则为空

[1]在函数名称或参数中给出了一些显式或隐式条件。

例外是针对例外情况。

如果您的函数旨在查找与给定对象关联的属性，而该对象没有此类属性，则返回null可能是合适的。如果对象不存在，则抛出异常可能更合适。如果该函数旨在返回属性列表，并且没有要返回的属性，则返回一个空列表很有意义-您将返回所有零个属性。

如果这样做在某种意义上是有意义的，则可以返回null：

public String getEmployeeName(int id){ ..}

在这种情况下，如果id与现有实体不对应，则返回null很有用，因为它可以让您区分出从合法错误中找不到匹配项的情况。

人们可能会认为这很糟糕，因为它可能会被滥用为表示错误状态的“特殊”返回值，该返回值并不是很好，有点像从函数返回错误代码，但由于用户必须检查返回值而感到困惑null，而不是捕获适当的异常，例如

public Integer getId(...){
   try{ ... ; return id; }
   catch(Exception e){ return null;}
}

它不一定是不良的设计-取决于许多设计决策，这取决于设计。

如果该方法的结果不能正常使用，则返回null是可以的：

object x = GetObjectFromCache();   // return null if it's not in the cache

如果确实总是会有一个非空的结果，那么最好抛出一个异常：

try {
   Controller c = GetController();    // the controller object is central to 
                                      //   the application. If we don't get one, 
                                      //   we're fubar

   // it's likely that it's OK to not have the try/catch since you won't 
   // be able to really handle the problem here
}
catch /* ... */ {
}

对于某些情况，您希望在发生故障时立即注意到它。

检查NULL并在失败情况下不声明（对于程序员错误）或抛出（对于用户或调用者错误）可能意味着以后的崩溃更难追踪，因为未找到原始的奇数情况。

此外，忽略错误可能导致安全漏洞。无效性可能来自缓冲区被覆盖之类的事实。现在，您不会崩溃，这意味着开发者有机会在您的代码中执行。

您看到返回null的其他选择吗？

我看到两种情况：

• findAnItem（id）。如果找不到该怎么办

在这种情况下，我们可以：返回Null或引发一个（已检查的）异常（或者可以创建一个项目并将其返回）

• listItemsMatching（条件），如果什么也没找到，应该返回什么？

在这种情况下，我们可以返回Null，返回空列表或引发Exception。

我认为，返回null可能不如其他方法好，因为它要求客户端记住检查null，程序员忘记并编写代码

x = find();
x.getField();  // bang null pointer exception

在Java中，抛出已检查的异常RecordNotFoundException可使编译器提醒客户端处理大小写。

我发现返回空列表的搜索非常方便-只需在列表中填充列表的所有内容，哦，它是空的，代码“可以正常工作”。

有时候，返回NULL是正确的做法，但是特别是当您处理不同种类的序列（数组，列表，字符串，所用的东西）时，最好返回零长度的序列，因为导致代码更短，并且希望可以更容易理解，而无需在API实现者方面花费更多的时间。

让他们在事实发生之后调用另一个方法，以找出先前的调用是否为空。;-)嘿，对于JDBC来说已经足够了

该线程背后的基本思想是防御性编程。也就是说，针对意外情况进行编码。有一系列不同的答复：

Adamski建议查看“空对象模式”，并对该建议投赞成票。

迈克尔·瓦伦蒂（Michael Valenty）还建议使用命名约定来告诉开发人员可能会发生什么。 如果这是NULL的原因，那么ZeroConcept建议正确使用Exception。和别的。

如果我们做出我们一直想进行防御性编程的“规则”，那么我们可以看到这些建议是有效的。

但是我们有2个开发方案。

由开发人员“创作”的类：作者

由另一个（也许）开发人员“消耗”的类：开发人员

无论类是否为具有返回值的方法返回NULL，开发人员都将需要测试对象是否有效。

如果开发人员无法执行此操作，则该类/方法不确定。也就是说，如果获取对象的“方法调用”没有执行其“通告”的操作（例如getEmployee），则它违反了合同。

作为课程的作者，我总是希望在创建方法时保持友善和防御（确定性）。

因此，鉴于需要检查NULL或NULL OBJECT（例如if（employee as NullEmployee.ISVALID）），并且可能需要对一组Employees进行检查，因此空对象方法是更好的方法。

但是我也喜欢Michael Valenty的建议，即命名必须返回null的方法，例如getEmployeeOrNull。

引发异常的作者正在删除开发人员测试对象有效性的选择，这对一组对象非常不利，并在分支其使用的代码时强制开发人员进行异常处理。

作为开发人员，我希望作者能够给我提供避免或编程他们的类/方法可能遇到的无效情况的能力。

因此，作为开发人员，我将通过一种方法针对NULL进行防御性编程。如果作者给我提供了一个合同，该合同始终返回一个对象（始终为NULL OBJECT）并且该对象具有用于测试对象有效性的方法/属性，那么我将使用该方法/属性来继续使用该对象，否则该对象无效，我将无法使用它。

最重要的是，类/方法的作者必须提供开发人员可以在防御性编程中使用的机制。即，该方法的意图更明确。

开发人员应始终使用防御性编程来测试从另一个类/方法返回的对象的有效性。

问候

格雷格·JF

其他选择包括：返回一些指示成功与否（或错误类型）的值，但是如果您只需要布尔值指示成功/失败，则返回null表示失败，而对象则不表示成功不太正确，然后返回true / false并通过参数获取对象。
另一种方法是使用异常来指示失败，但是在这里-实际上还有很多声音，说这是一种BAD做法（因为使用异常可能很方便，但也有很多缺点）。
因此，我个人认为返回null表示出现问题并随后进行检查（以实际上知道您是否成功），这没有什么不好。同样，一味地认为您的方法将不会返回NULL，然后将其基于代码，可能会导致其他（有时很难找到）错误（尽管在大多数情况下，它将使您的系统崩溃：），因为您将引用早晚为0x00000000）。

在复杂程序的开发过程中可能会出现意外的空函数，并且像死代码一样，这种现象表明程序结构中存在严重缺陷。

空函数或方法通常用作对象框架中可重新引导函数或可重写方法的默认行为。

Null_function @维基百科

好吧，它肯定取决于方法的目的。有时，更好的选择是引发异常。这全视情况而定。

如果代码是这样的：

command = get_something_to_do()

if command:  # if not Null
    command.execute()

如果您有一个虚拟对象，其execute（）方法不执行任何操作，并且在适当的情况下返回该对象而不是Null，则无需检查Null情况，而可以执行以下操作：

get_something_to_do().execute()

因此，这里的问题不在检查NULL与检查异常之间，而是在调用者不得不以不同的方式（无论以何种方式）处理特殊的不区分大小写之间。

对于我的用例，我需要从方法返回一个Map，然后寻找一个特定的键。但是，如果我返回一个空的Map，它将导致NullPointerException，然后返回null而不是一个空的Map不会有太大的不同。但是从Java8开始，我们可以使用Optional。以上正是引入可选概念的原因。

G'day，

当您无法创建新对象时，返回NULL是许多API的标准做法。

为什么不知道这是一个糟糕的设计，我不知道。

编辑：对于没有例外的语言，例如C，多年来的惯例，这都是正确的。

高温超导

'Avahappy，