我认为为什么空是不可取的简单总结是，无意义的状态不应该是可表示的。

假设我在建模一扇门。它可以处于三种状态之一:打开、关闭但未解锁、关闭并锁定。现在我可以用

class Door
    private bool isShut
    private bool isLocked

如何将三个状态映射到这两个布尔变量是很清楚的。但这就留下了第四种不希望出现的状态:isShut==false && isLocked==true。因为我所选择的类型承认这种状态，所以我必须花费精力来确保类永远不会进入这种状态(可能通过显式地编码一个不变量)。相反，如果我使用一种具有代数数据类型的语言或允许我定义的受控枚举

type DoorState =
    | Open | ShutAndUnlocked | ShutAndLocked

那么我就可以定义

class Door
    private DoorState state

再也没有什么担心了。类型系统将确保类Door的实例只有三种可能的状态。这正是类型系统所擅长的——在编译时显式地排除了一整类错误。

null的问题在于，每个引用类型都会在其空间中获得这个通常不希望的额外状态。字符串变量可以是任意字符序列，也可以是这个疯狂的额外空值，它没有映射到我的问题域。三角形对象有三个点，它们本身有X和Y值，但不幸的是，这些点或三角形本身可能是这个疯狂的空值，对我所处的绘图域毫无意义。等。

当您确实打算对一个可能不存在的值建模时，那么您应该显式地选择它。如果我打算对人建模的方式是每个人都有一个名字和一个姓，但只有一些人有中间名，那么我想说一些像这样的话

class Person
    private string FirstName
    private Option<string> MiddleName
    private string LastName

这里的string被假定为非空类型。这样，在尝试计算某人名字的长度时，就不需要建立棘手的不变量，也不会出现意外的nullreferenceexception。类型系统确保任何处理midlename的代码都考虑到它为None的可能性，而任何处理FirstName的代码都可以安全地假设那里有一个值。

例如，使用上面的类型，我们可以编写这个愚蠢的函数:

let TotalNumCharsInPersonsName(p:Person) =
    let middleLen = match p.MiddleName with
                    | None -> 0
                    | Some(s) -> s.Length
    p.FirstName.Length + middleLen + p.LastName.Length

没有烦恼。相反，在一种语言中，对字符串等类型的可空引用，则假设

class Person
    private string FirstName
    private string MiddleName
    private string LastName

你最终创作的东西就像

let TotalNumCharsInPersonsName(p:Person) =
    p.FirstName.Length + p.MiddleName.Length + p.LastName.Length

如果传入的Person对象没有所有东西都是非空的不变式，那么它就会爆炸，或者

let TotalNumCharsInPersonsName(p:Person) =
    (if p.FirstName=null then 0 else p.FirstName.Length)
    + (if p.MiddleName=null then 0 else p.MiddleName.Length)
    + (if p.LastName=null then 0 else p.LastName.Length)

或者

let TotalNumCharsInPersonsName(p:Person) =
    p.FirstName.Length
    + (if p.MiddleName=null then 0 else p.MiddleName.Length)
    + p.LastName.Length

假设p确保first/last在那里，但middle可以为空，或者你可能会检查抛出不同类型的异常，或者谁知道呢。所有这些疯狂的实现选择和需要考虑的事情突然出现，因为有这种愚蠢的可代表价值，你不想要或不需要。

Null通常会增加不必要的复杂性。复杂性是所有软件的敌人，您应该在合理的情况下努力降低复杂性。

(Note well that there is more complexity to even these simple examples. Even if a FirstName cannot be null, a string can represent "" (the empty string), which is probably also not a person name that we intend to model. As such, even with non-nullable strings, it still might be the case that we are "representing meaningless values". Again, you could choose to battle this either via invariants and conditional code at runtime, or by using the type system (e.g. to have a NonEmptyString type). The latter is perhaps ill-advised ("good" types are often "closed" over a set of common operations, and e.g. NonEmptyString is not closed over .SubString(0,0)), but it demonstrates more points in the design space. At the end of the day, in any given type system, there is some complexity it will be very good at getting rid of, and other complexity that is just intrinsically harder to get rid of. The key for this topic is that in nearly every type system, the change from "nullable references by default" to "non-nullable references by default" is nearly always a simple change that makes the type system a great deal better at battling complexity and ruling out certain types of errors and meaningless states. So it is pretty crazy that so many languages keep repeating this error again and again.)

默认情况下，不希望引用/指针为空。

我不认为这是null的主要问题，null的主要问题是它们可能意味着两件事:

引用/指针是未初始化的:这里的问题与一般的可变性相同。首先，它使分析代码变得更加困难。 变量为空实际上意味着一些事情:这是Option类型实际形式化的情况。

支持Option类型的语言通常也禁止或不鼓励使用未初始化的变量。

选项类型的工作方式包括简化检查null情况的策略，例如模式匹配。

为了有效，需要在语言中直接支持Option类型。否则就需要大量样板代码来模拟它们。模式匹配和类型推断是使Option类型易于使用的两个关键语言特性。例如:

在f#:

//first we create the option list, and then filter out all None Option types and 
//map all Some Option types to their values.  See how type-inference shines.
let optionList = [Some(1); Some(2); None; Some(3); None]
optionList |> List.choose id //evaluates to [1;2;3]

//here is a simple pattern-matching example
//which prints "1;2;None;3;None;".
//notice how value is extracted from op during the match
optionList 
|> List.iter (function Some(value) -> printf "%i;" value | None -> printf "None;")

然而，在像Java这样没有直接支持Option类型的语言中，我们会有这样的东西:

//here we perform the same filter/map operation as in the F# example.
List<Option<Integer>> optionList = Arrays.asList(new Some<Integer>(1),new Some<Integer>(2),new None<Integer>(),new Some<Integer>(3),new None<Integer>());
List<Integer> filteredList = new ArrayList<Integer>();
for(Option<Integer> op : list)
    if(op instanceof Some)
        filteredList.add(((Some<Integer>)op).getValue());

替代解决方案，如消息吃nil

Objective-C's "message eating nil" is not so much a solution as an attempt to lighten the head-ache of null checking. Basically, instead of throwing a runtime exception when trying to invoke a method on a null object, the expression instead evaluates to null itself. Suspending disbelief, it's as if each instance method begins with if (this == null) return null;. But then there is information loss: you don't know whether the method returned null because it is valid return value, or because the object is actually null. It's a lot like exception swallowing, and doesn't make any progress addressing the issues with null outlined before.

选项类型的好处并不在于它们是可选的。而是所有其他类型的人都不是。

有时，我们需要能够表示一种“null”状态。有时我们必须表示一个“无值”选项以及变量可能接受的其他可能值。因此，一种完全不允许这一点的语言将会有点残缺。

但通常情况下，我们并不需要它，并且允许这样的“null”状态只会导致歧义和混乱:每次在. net中访问引用类型变量时，我都必须考虑它可能是空的。

通常情况下，它实际上永远不会为空，因为程序员构造的代码使它永远不会发生。但是编译器不能验证它，每次你看到它，你都要问自己“这个可以为空吗?”我需要检查这里是否为空吗?”

理想情况下，在许多情况下，null没有意义，它不应该被允许。

在. net中实现这一点很棘手，因为几乎所有东西都可以为空。您必须依赖所调用代码的作者100%遵守纪律和一致，并清楚地记录了什么可以为空，什么不可以为空，否则您必须偏执狂，检查所有内容。

但是，如果默认情况下类型不能为空，则不需要检查它们是否为空。你知道它们永远不可能为空，因为编译器/类型检查器会强制你这样做。

然后，我们只需要一个后门，在极少数情况下，我们确实需要处理一个空状态。然后可以使用“选项”类型。然后，在我们有意识地决定我们需要能够表示“无值”的情况下，我们允许null，而在其他任何情况下，我们知道值永远不会为null。

正如其他人所提到的，在c#或Java中，null可能意味着以下两种情况之一:

变量未初始化。理想情况下，这种情况不应该发生。一个变量不应该存在，除非它被初始化。 变量包含一些“可选”数据:它需要能够表示没有数据的情况。这有时是必要的。也许你试图在一个列表中找到一个对象，而你事先不知道它是否在那里。然后我们需要能够表示“没有找到对象”。

第二种意思必须保留，但第一种意思应该完全消除。甚至第二种意思也不应该是默认的。如果我们需要，我们可以选择加入。但当我们不需要某些东西为可选时，我们希望类型检查器保证它永远不会为空。

Robert Nystrom在这里提供了一篇不错的文章:

http://journal.stuffwithstuff.com/2010/08/23/void-null-maybe-and-nothing/

描述了他在为Magpie编程语言添加缺席和失败支持时的思维过程。

我认为为什么空是不可取的简单总结是，无意义的状态不应该是可表示的。

假设我在建模一扇门。它可以处于三种状态之一:打开、关闭但未解锁、关闭并锁定。现在我可以用

class Door
    private bool isShut
    private bool isLocked

如何将三个状态映射到这两个布尔变量是很清楚的。但这就留下了第四种不希望出现的状态:isShut==false && isLocked==true。因为我所选择的类型承认这种状态，所以我必须花费精力来确保类永远不会进入这种状态(可能通过显式地编码一个不变量)。相反，如果我使用一种具有代数数据类型的语言或允许我定义的受控枚举

type DoorState =
    | Open | ShutAndUnlocked | ShutAndLocked

那么我就可以定义

class Door
    private DoorState state

再也没有什么担心了。类型系统将确保类Door的实例只有三种可能的状态。这正是类型系统所擅长的——在编译时显式地排除了一整类错误。

null的问题在于，每个引用类型都会在其空间中获得这个通常不希望的额外状态。字符串变量可以是任意字符序列，也可以是这个疯狂的额外空值，它没有映射到我的问题域。三角形对象有三个点，它们本身有X和Y值，但不幸的是，这些点或三角形本身可能是这个疯狂的空值，对我所处的绘图域毫无意义。等。

当您确实打算对一个可能不存在的值建模时，那么您应该显式地选择它。如果我打算对人建模的方式是每个人都有一个名字和一个姓，但只有一些人有中间名，那么我想说一些像这样的话

class Person
    private string FirstName
    private Option<string> MiddleName
    private string LastName

这里的string被假定为非空类型。这样，在尝试计算某人名字的长度时，就不需要建立棘手的不变量，也不会出现意外的nullreferenceexception。类型系统确保任何处理midlename的代码都考虑到它为None的可能性，而任何处理FirstName的代码都可以安全地假设那里有一个值。

例如，使用上面的类型，我们可以编写这个愚蠢的函数:

let TotalNumCharsInPersonsName(p:Person) =
    let middleLen = match p.MiddleName with
                    | None -> 0
                    | Some(s) -> s.Length
    p.FirstName.Length + middleLen + p.LastName.Length

没有烦恼。相反，在一种语言中，对字符串等类型的可空引用，则假设

class Person
    private string FirstName
    private string MiddleName
    private string LastName

你最终创作的东西就像

let TotalNumCharsInPersonsName(p:Person) =
    p.FirstName.Length + p.MiddleName.Length + p.LastName.Length

如果传入的Person对象没有所有东西都是非空的不变式，那么它就会爆炸，或者

let TotalNumCharsInPersonsName(p:Person) =
    (if p.FirstName=null then 0 else p.FirstName.Length)
    + (if p.MiddleName=null then 0 else p.MiddleName.Length)
    + (if p.LastName=null then 0 else p.LastName.Length)

或者

let TotalNumCharsInPersonsName(p:Person) =
    p.FirstName.Length
    + (if p.MiddleName=null then 0 else p.MiddleName.Length)
    + p.LastName.Length

假设p确保first/last在那里，但middle可以为空，或者你可能会检查抛出不同类型的异常，或者谁知道呢。所有这些疯狂的实现选择和需要考虑的事情突然出现，因为有这种愚蠢的可代表价值，你不想要或不需要。

Null通常会增加不必要的复杂性。复杂性是所有软件的敌人，您应该在合理的情况下努力降低复杂性。

(Note well that there is more complexity to even these simple examples. Even if a FirstName cannot be null, a string can represent "" (the empty string), which is probably also not a person name that we intend to model. As such, even with non-nullable strings, it still might be the case that we are "representing meaningless values". Again, you could choose to battle this either via invariants and conditional code at runtime, or by using the type system (e.g. to have a NonEmptyString type). The latter is perhaps ill-advised ("good" types are often "closed" over a set of common operations, and e.g. NonEmptyString is not closed over .SubString(0,0)), but it demonstrates more points in the design space. At the end of the day, in any given type system, there is some complexity it will be very good at getting rid of, and other complexity that is just intrinsically harder to get rid of. The key for this topic is that in nearly every type system, the change from "nullable references by default" to "non-nullable references by default" is nearly always a simple change that makes the type system a great deal better at battling complexity and ruling out certain types of errors and meaningless states. So it is pretty crazy that so many languages keep repeating this error again and again.)

微软研究院有个有趣的项目叫做

spec#

它是一个c#扩展，具有非空类型和一些机制来检查你的对象是否为空，尽管，恕我直言，应用契约设计原则可能更合适，对许多由空引用引起的麻烦情况更有帮助。