空引用真的是一件坏事吗？

 Customer c = Customer.GetByLastName("Goodman"); // returns null if not found
if (c != null)
{
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
 

 if (Customer.ExistsWithLastName("Goodman"))
{
    Customer c = Customer.GetByLastName("Goodman") // throws error if not found
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!"); 
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
 

#1 楼

null是邪恶的

InfoQ上有一个有关此主题的演讲：空引用：Tony Hoare的十亿美元错误

选项类型

函数式编程的替代方法是使用Option类型，该类型可以包含SOME value或NONE。

好文章“ Option”模式讨论了Option类型并为Java提供了它的实现。 >
我还发现了有关此问题的Java错误报告：向Java添加Nice Option类型以防止NullPointerExceptions。 Java 8中引入了所需的功能。

#2 楼

问题在于，从理论上讲，任何对象都可以为null并在尝试使用它时抛出异常，因此面向对象的代码基本上是未爆炸炸弹的集合。

优美的错误处理在功能上可以与null-check if语句相同。但是，当您说服自己不可能为null时，实际上是null会发生什么呢？ Kerboom。不管接下来发生什么，我都敢打赌1）它不会很优美，2）您不会喜欢它。

也不要忽略“易于调试”的价值。成熟的生产规范是一种疯狂的，无所适从的生物。任何可以让您更深入了解问题出在哪里以及可以节省您挖掘时间的事情。

#3 楼

在代码中使用空引用存在几个问题。

首先，它通常用于指示特殊状态。正常情况下，不像在专业化时那样为每个状态定义新的类或常量，而是使用null引用使用有损的，广义的类型/值。

其次，当null为空时，调试代码变得更加困难引用出现，并且即使您可以跟踪其上游执行路径，也要尝试确定生成它的原因，哪个状态有效以及其原因。
第三，空引用引入了要测试的其他代码路径。

第四，一旦将空引用用作参数以及返回值的有效状态，防御性编程（针对由设计引起的状态）就需要在各个地方进行更多的空引用检查……以防万一第五，该语言的运行时在对对象的方法表执行选择器查找时已经在执行类型检查。因此，通过检查对象的类型是否有效来重复工作，然后让运行时检查有效的对象的类型以调用其方法。

为什么不使用NullObject模式来利用运行时的检查，以使其调用特定于该状态的NOP方法（符合常规状态的接口），同时还消除了整个代码库中对null引用的所有额外检查？

通过为每个要表示特殊状态的接口创建一个NullObject类，它涉及更多的工作。但是至少专业化是隔离到每个特殊状态的，而不是可能存在该状态的代码。 IOW，减少了测试的数量，因为方法中的替代执行路径更少。

评论

---

...因为弄清楚谁生成了（或者更不用说更改或初始化）填充了您认为有用的对象的垃圾数据比跟踪NULL引用容易得多？我不买它，尽管我大多被困在静态类型的土地上。

–dash-tom-bang
2010-10-19 0:00

---

但是，垃圾数据比空引用少得多。特别是在托管语言中。

–迪恩·哈丁（Dean Harding）
2010-10-19在1:05

---

-1为空对象。

– DeadMG
2012年7月13日在22:18

---

点（4）和（5）是可靠的，但NullObject不是补救措施。您将陷入更糟糕的陷阱-逻辑（工作流）错误。当您完全了解当前情况时，可以肯定会有所帮助，但是盲目使用（而不是null）会花费更多。

–greenoldman
13年5月22日在13:29

---

@ gnasher729，尽管Objective-C的运行时不会像Java和其他系统那样抛出空指针异常，但由于我在答案中概述的原因，它并不能更好地使用空引用。例如，如果[self.navigationController.presentingViewController中没有导航控制器，则dismissViewControllerAnimated：是，完成：无]；运行时将其视为无操作序列，视图不会从显示中删除，并且您可能坐在Xcode前面，花了几个小时试图找出原因。

– Huperniketes
2015年4月13日在2:31

---

#4 楼

除非您不期望它们，否则Null并不是那么糟糕。您应该需要在代码中明确指定期望为null的语言，这是一种语言设计问题。请考虑以下问题：

 Customer? c = Customer.GetByLastName("Goodman");
// note the question mark -- 'c' is either a Customer or null
if (c != null)
{
    // c is not null, therefore its type in this block is
    // now 'Customer' instead of 'Customer?'
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
 

如果尝试在Customer?上调用方法，则应该得到编译时错误。更多语言不执行此操作（IMO）的原因是，它们不提供根据其作用域来更改变量的类型的方法。如果语言可以处理该问题，则可以完全解决该问题。类型系统。使用option-types和Maybe也可以解决此问题，但是我不太熟悉。我更喜欢这种方式，因为理论上正确的代码只需要添加一个字符即可正确编译。

#5 楼

有很多很好的答案可以解决null的不幸症状，所以我想提出一个替代的论点：空是类型系统中的缺陷。

类型系统的目的是确保程序的不同组成部分可以“适当地”组合在一起；一个良好类型的程序不能“脱离轨道”进入未定义的行为。

考虑一下Java的假设方言，或您喜欢的任何静态类型语言，可以在其中将字符串"Hello, world!"分配给任何类型的任何变量：

 Foo foo1 = new Foo();  // Legal
Foo foo2 = "Hello, world!"; // Also legal
Foo foo3 = "Bonjour!"; // Not legal - only "Hello, world!" is allowed
 

可以像这样检查变量：

 if (foo1 != "Hello, world!") {
    bar(foo1);
} else {
    baz();
}
 

这没有什么不可能的，有人可以设计这样的如果他们愿意的话。特殊值不必是"Hello, world!"-它可能是数字42，元组(1, 4, 9)或null。但是为什么要这么做呢？类型为Foo的变量应仅包含Foo s-这就是类型系统的重点！ null不是Foo，而是"Hello, world!"。更糟糕的是，null不是任何类型的值，您无法执行任何操作！

程序员永远无法确定变量实际上是否包含Foo，程序也无法保证；为了避免未定义的行为，必须先将"Hello, world!"的变量用作Foo，然后再对其进行检查。请注意，在前面的代码段中执行字符串检查不会传播foo1确实是一个Foo的事实-为了安全起见，bar也可能也会进行自己的检查。

比较使用具有模式匹配的Maybe / Option类型：

 case maybeFoo of
 |  Just foo => bar(foo)
 |  Nothing => baz()
 

在Just foo子句内部，您和程序都肯定知道我们的Maybe Foo变量确实确实包含Foo值-信息沿调用链传播，并且bar不需要进行任何检查。由于Maybe Foo是与Foo不同的类型，因此您不得不处理它可能包含Nothing的可能性，因此，您永远不能被NullPointerException蒙蔽。您可以更轻松地对程序进行推理，并且知道所有Foo类型的变量确实都包含Foo，编译器可以省略空检查。每个人都赢。

#6 楼

一个null指针是一个工具，不是敌人。您只应该使用'em right'。

想一想，查找和修复典型的无效指针错误所需的时间要比查找和修复空指针错误所需的时间长。检查指向null的指针很容易。验证非空指针是否指向有效数据是一种PITA。

如果仍然不满意，请向您的方案中添加大量的多线程，然后再考虑一下。

故事的寓意：不要把孩子扔到水里。而且不要怪事故的工具。很久以前就发明了零的那个人很聪明，因为那天你可以命名为“ nothing”。 null指针与之相距不远。


编辑：尽管NullObject模式似乎比可能为null的引用更好，但它本身会带来问题：调用NullObject的引用（根据理论）应在调用方法时不执行任何操作。因此，由于错误地分配了错误的引用，可能会引入细微的错误，这些引用现在可以保证为非null（yehaa！），但会执行有害的操作：什么也不做。使用NPE，问题的根源就显而易见了。对于表现出某种行为（但有误）的NullObject，我们引入了错误（过早）被发现的风险。这并非偶然地类似于无效指针问题，并且具有类似的结果：该引用指向的东西看起来像有效的数据，但并非如此，它引入了数据错误并且可能难以追踪。坦白地说，在这些情况下，我会眨眼间更喜欢现在立即失效的NPE，而不是逻辑/数据错误，后者后来突然击中了我。还记得IBM关于错误成本取决于在哪个阶段发现错误的研究吗？
当在NullObject上调用方法，调用属性getter或函数或方法通过out返回值时，什么都不做的想法不成立。假设返回值是int，我们决定“不执行任何操作”表示“返回0”。但是我们如何确定0是正确的“无”（不是）返回呢？毕竟，NullObject不应做任何事情，但是当要求输入值时，它必须以某种方式做出反应。失败不是一种选择：我们使用NullObject来防止NPE，我们肯定不会将它与另一个异常（未实现，除以零，...）进行交易，对吗？那么当您必须退货时，如何正确地什么也不退货呢？

我无能为力，但是当有人尝试将NullObject模式应用于每个问题时，它看起来更像是在尝试维修一个又一个错误。毫无疑问，在某些情况下，这是一个很好且有用的解决方案，但它肯定不是所有情况下的灵丹妙药。

#7 楼

（将我的帽子扔给一个老问题；））

null的具体问题是它破坏了静态输入。

如果我有Thing t，则编译器可以保证我可以调用t.doSomething()。好吧，除非在运行时t为空。现在所有赌注都关闭了。编译器说还可以，但是我后来发现t实际上不是doSomething()。因此，我不能等待编译器捕获类型错误，而必须等到运行时才能捕获它们。我不妨只使用Python！

因此，从某种意义上说，null将动态类型引入到静态类型的系统中，并具有预期的结果。

区别之间的区别由零或对数的对数等表示，当i = 0时，它仍然是整数。编译器仍然可以保证其类型。问题在于逻辑以一种逻辑所不允许的方式错误地应用了该值...但是，如果逻辑做到了，那几乎就是一个错误的定义。

（顺便说一句，编译器可以解决一些问题，就像在编译时标记i = 1 / 0这样的表达式一样，但是您不能真正期望编译器遵循函数并确保参数都与函数的逻辑一致。 >
实际的问题是，您需要做很多额外的工作，并添加null检查以在运行时保护自己，但是如果忘记了该怎么办？编译器阻止您进行赋值：


字符串s = new Integer（1234）;


为什么要允许赋值（ null），这将破坏对s的取消引用？通过在代码中混合“无值”和“类型化”引用，给程序员增加了负担。而且，当NullPointerExceptions发生时，对其进行跟踪可能会更加耗时。您不是让静态语言说“这很可能是对期望的东西的引用。”而不是依靠静态类型来说“这是对期望的东西的引用”。

#8 楼

空引用是一个错误，因为它们允许使用非意义的代码：

foo = null
foo.bar()

如果使用类型系统，则还有其他选择：

 Maybe<Foo> foo = null
foo.bar() // error{Maybe<Foo> does not have any bar method}
 

通常的想法是将变量放在一个盒子里，而你唯一要做的就是

Haskell可以从头开始（Maybe），在C ++中可以利用boost::optional<T>，但是仍然可以得到未定义的行为...

#9 楼

还有什么选择？


可选类型和模式匹配。由于我不了解C＃，因此这里有一段虚构的语言，称为Scala＃：-)

 Customer.GetByLastName("Goodman")    // returns Option[Customer]
match
{
    case Some(customer) =>
    Console.WriteLine(customer.FirstName + " " + customer.LastName + " is awesome!");

    case None =>
    Console.WriteLine("There was no customer named Goodman.  How lame!");
}
 

#10 楼

空值的问题在于允许它们使用的语言在很大程度上迫使您针对它进行防御性编程。要确保




不为空的对象确实绝不会花费很多精力（远远超过尝试使用防御性的if-block） null，并且
您的防御机制实际上可以有效地处理所有潜在的NPE。

因此，null最终是一件昂贵的事情。 br />

#11 楼

问题不仅仅在于null，还在于您无法在许多现代语言中指定非null引用类型。例如，您的代码可能像

 public void MakeCake(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    egg.Crack();
    MixingBowl.Mix(egg, flour, milk);
    // etc
}

// inside Mixing bowl class
public void Mix(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    //... etc
}
 

当类引用被传递时，防御性编程鼓励您再次检查所有参数是否为null，即使您只是事先检查了它们是否为空，尤其是在构建被测单元时。在整个代码库中，可以轻松地对同一引用进行10次空值检查！

如果在获取东西时可以使用普通的可空类型，然后在那儿处理空值，那会更好吗？然后将其作为不可为null的类型传递给所有小辅助函数和类，而不始终检查是否为null？

那就是Option解决方案的重点-不允许您打开错误状态，但允许设计隐式不能接受空参数的函数。类型的“默认”实现是可为空还是不可为空，与使两个工具都可用的灵活性相比，重要性不那么重要。

http://twistedoakstudios.com/blog/Post330_non-nullable-类型-vs-c-fixing-the-billion-dollar-mistake

这也被列为C＃的＃2投票最多的功能-> https://visualstudio.uservoice.com/forums/ 121579-visual-studio / category / 30931-languages-c

#12 楼

这个问题是您的编程语言在运行程序之前尝试证明其正确性的程度。用静态类型语言证明您具有正确的类型。通过使用非空引用的默认值（带有可选的可空引用），您可以消除许多传递null而不应该传递null的情况。问题在于，在程序正确性方面，处理非空引用的额外努力是否值得。

#13 楼

空是邪恶的。但是，缺少null可能会带来更大的危害。

问题是，在现实世界中，您经常会遇到没有数据的情况。您的示例中没有空值的版本仍然会爆炸-您在逻辑上的错误并忘记了检查Goodman，或者在检查与查找之间，Goodman结婚了。 （如果您认为Moriarty在看代码的每一部分并试图使您绊倒，这有助于评估逻辑。）

当Goodman不在那里时，查找该怎么办？没有空值，您必须返回某种默认客户-现在您要向该默认客户销售商品。

从根本上讲，无论什么情况下，代码都能正常工作更重要或它正常工作。如果不当行为比无行为更可取，那么您就不希望使用null。 （有关如何正确选择该示例的示例，请考虑首次发射ArianeV。未捕获的/ 0错误导致火箭硬转，并且因此而自行解散时发射自毁式火箭。）它试图计算出助推器被点燃后实际上不再具有任何作用-尽管例行返回垃圾，它仍然会进入轨道。）

我至少选择了100次中的99次使用空值。不过，我会为自己的版本感到高兴。

#14 楼

针对最常见的情况进行优化。

始终需要检查null是很乏味的-您希望能够只掌握Customer对象并使用它。

在通常情况下，这应该可以正常工作-您进行查找，获取对象并使用它。

在特殊情况下，您会（随机）按名称查找客户，不知道该记录/对象是否存在，则需要某种指示，以确保此操作失败。在这种情况下，答案是抛出RecordNotFound异常（或让下面的SQL提供程序为您执行此操作）。

如果您处在不知道是否可以信任的情况下输入的数据（参数），可能是因为它是由用户输入的，因此，您还可以提供“ TryGetCustomer（name，out customer）”模式。与int.Parse和int.TryParse的交叉引用。

#15 楼

异常不是eval！

出现异常是有原因的。如果您的代码运行不正常，则有一个天才模式，称为异常，它告诉您某些事情是错误的。

通过避免使用空对象，您可以隐藏这些异常的一部分。我没有在OP示例中大惊小怪，他将空指针异常转换为类型正确的异常，这实际上可能是一件好事，因为它提高了可读性。就像@Jonas指出的那样，当您采用Option类型解决方案时，您将隐藏异常。

比在生产应用程序中，而不是单击按钮选择空选项时抛出异常，什么都没有发生。代替抛出空指针，将抛出异常，并且我们可能会得到该异常的报告（就像在许多生产应用程序中我们都具有这种机制一样），然后我们才可以实际对其进行修复。

使代码安全通过避免异常是一个坏主意，通过修复异常使您的代码防弹，这就是我会选择的路径。

#16 楼

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


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

查看此博客文章以获取详细说明：http://www.yegor256.com/2014/05/13/why-null -is-bad.html

#17 楼

我对null有一个简单的反对意见：

通过引入歧义性完全破坏了代码的语义。

通常您希望结果是某种类型的。这在语义上是合理的。假设您向数据库查询了具有特定id的用户，则您期望结果为特定类型（= user）。但是，如果没有该ID的用户怎么办？
一种（错误的）解决方案是：添加一个null值。所以结果是模棱两可的：是user还是null。但是null不是预期的类型。这就是代码气味的开始。

避免null时，您可以使代码在语义上清晰明了。

null周围总有很多方法：重构到集合Null-objects，optionals等

#18 楼

Nulls有问题，因为必须对其进行显式检查，但编译器无法警告您忘记检查它们。只有费时的静态分析才能告诉您这一点。幸运的是，有几种不错的选择。

使变量超出范围。当程序员过早声明变量或将变量保留太长时间时，null常常用作占位符。最好的方法就是简单地摆脱变量。在您输入有效值之前，不要声明它。这并不是您想像的那样困难的限制，它使您的代码更加整洁。

使用空对象模式。有时，缺少的值是您系统的有效状态。空对象模式是一个很好的解决方案。它避免了进行常量显式检查的需要，但仍允许您表示一个空状态。正如某些人所声称的那样，它不是“在错误条件下书写”，因为在这种情况下，空状态是有效的语义状态。话虽如此，当空状态不是有效的语义状态时，您不应使用此模式。您应该只将变量移出范围。

使用Maybe / Option。首先，这使编译器警告您需要检查缺少的值，但它所做的不仅仅是将一种显式检查替换为另一种。使用Options，您可以链接您的代码，并继续进行操作，就好像您的值存在一样，而无需真正检查直到最后一刻。在Scala中，示例代码如下所示：

 val customer = customerDb getByLastName "Goodman"
val awesomeMessage =
  customer map (c => s"${c.firstName} ${c.lastName} is awesome!")
val notFoundMessage = "There was no customer named Goodman.  How lame!"
println(awesomeMessage getOrElse notFoundMessage)
 

在第二行中，我们在构建令人敬畏的消息，我们没有明确检查是否找到了客户，而美观是我们不需要的。直到最后一行，可能是以后的很多行，甚至是在不同的模块中，我们才明确地考虑到如果Option是None会发生什么。不仅如此，如果我们忘记这样做，就不会进行类型检查。即使这样，它也可以以非常自然的方式完成，而无需显式的if语句。

与null进行对比，它在这里进行类型检查就很好了，但是您必须在每个步骤上进行显式检查如果您很幸运在用例中进行单元测试，则可能会导致整个应用程序在运行时崩溃。只是不值得麻烦。

#19 楼

NULL的中心问题是它使系统不可靠。
1980年，托尼·霍尔（Tony Hoare）在致图灵奖的论文中写道：


因此，我对ADA的创始人和设计师的最佳建议被忽略了。 …。不允许将这种语言以当前状态使用在可靠性至关重要的应用中，例如，核电站，巡航导弹，预警系统，弹道导弹防御系统。下一个由于编程语言错误而误入歧途的火箭可能不是探索性的
金星无故旅行的太空火箭：它可能是核弹头
爆炸了我们自己的城市。与不安全的汽车，有毒的农药或核电站的事故相比，不可靠的编程
生成不可靠程序的语言对我们的环境和社会构成更大的风险
。警惕
降低风险，而不是增加风险。


ADA语言自那以来发生了很大变化，但是Java，C＃和许多其他流行的语言仍然存在此类问题。语言。

开发者有责任在客户和供应商之间创建合同。例如，在C＃中，就像在Java中一样，您可以使用Generics通过创建只读Null（两个选项）来最小化NullableClass<T>引用的影响：

 class NullableClass<T>
{
     public HasValue {get;}
     public T Value {get;}
}
 

，然后将其用作

 NullableClass<Customer> customer = dbRepository.GetCustomer('Mr. Smith');
if(customer.HasValue){
  // one logic with customer.Value
}else{
  // another logic
} 
 

，或使用带有C＃扩展方法的两个选项样式：

 customer.Do(
      // code with normal behaviour
      ,
      // what to do in case of null
) 
 

差异很大。作为方法的客户，您知道会发生什么。团队可以具有以下规则：

如果类的类型不是NullableClass，则其实例必须不为null。

团队可以通过按合同设计和在编译时进行静态检查来增强此想法，例如，前提是：

 function SaveCustomer([NotNullAttribute]Customer customer){
     // there is no need to check whether customer is null 
     // it is a client problem, not this supplier
}
 

或字符串

 function GetCustomer([NotNullAndNotEmptyAttribute]String customerName){
     // there is no need to check whether customerName is null or empty 
     // it is a client problem, not this supplier
}
 

这些方法可以大大增加应用程序可靠性和软件质量。合同设计是Hoare逻辑的一个例子，1988年，Bertrand Meyer在他著名的面向对象的软件构造书和Eiffel语言中填充了Hoare逻辑，但是在现代软件制作中并未无效使用它。

#20 楼

基本上，中心思想是应该在编译时而不是运行时捕获空指针引用问题。因此，如果您正在编写一个带有某些对象的函数，并且您不希望任何人使用空引用来调用它，则类型系统应该允许您指定该要求，以便编译器可以使用它来提供对函数的调用永远不会保证的保证。如果调用者不满足您的要求，则进行编译。这可以通过多种方式来完成，例如，修饰类型或使用选项类型（在某些语言中也称为可空类型），但是显然，对于编译器设计者而言，这还有很多工作。

我认为这是可以理解的为什么在1960年代和70年代，编译器设计者并没有全力以赴地实现这一想法，因为计算机的资源有限，编译器需要保持相对简单，并且没人真正知道这会导致40年的失败。

#21 楼

否。

语言无法解决null这样的特殊值是该语言的问题。如果您查看像Kotlin或Swift这样的语言，它们迫使作者在每次遇到时都明确地处理null值的可能性，那么就没有危险。

在诸如此类的语言中，该语言允许null为任意类型的值，但不提供任何构造以供日后确认，这导致事情出乎意料（尤其是从其他地方传递给您时），从而导致崩溃。那是邪恶的：让您使用null而不用处理它。

#22 楼

如果在运行代码以为其计算值之前在语义上可以访问引用或指针类型的存储位置，那么对于应该发生的事情没有任何完美的选择。使此类位置默认为空指针引用是一种可能的选择，该指针可以自由读取和复制，但是如果取消引用或建立索引，则会出错。其他选择包括：


将位置默认为空指针，但是不允许代码查看它们（甚至确定它们为空）而不会崩溃。可能提供一种将指针设置为null的显式方法。

将位置默认为null指针，如果尝试读取一个指针，则崩溃，但是提供了一种非崩溃的方法来测试是否指针为空。还提供一种将指针设置为null的显式方法。

将位置默认为指向由特定编译器提供的指定类型的默认实例的指针。

将位置默认为

具有指向某些特定程序提供的指示类型的默认实例的指针。

可以进行任何空指针访问（不仅是取消引用操作），还可以调用某些程序提供的例程来提供实例。 >
设计语言语义，以使除不可访问的编译器临时文件外，不存在存储位置的集合，直到在所有成员上都运行了初始化例程之前（必须提供数组构造函数之类的东西）一个默认实例，一个将返回一个实例的函数或可能是一对函数-一个用于返回实例，如果在构造数组期间发生异常，则一个函数将在先前构造的实例上调用）。 br />

最后一种选择可能会吸引人，特别是如果一种语言同时包含可为null和不可为null的类型（一种可以为任何类型调用特殊的数组构造函数，但是仅在创建非可为null的类型的数组时才需要调用它们），但是在发明空指针的那段时间可能不可行。在其他选择中，似乎没有一个比允许复制空指针但不对其取消引用或索引更具吸引力。方法4可以很方便地选择，并且实现起来应该很便宜，但是它当然不是唯一的选择。要求指针默认情况下必须指向某个特定的有效对象要比使指针默认为可以读取或复制但不能取消引用或索引的空值要差得多。