因为人们似乎忽略了它:null是模棱两可的。

Alice的出生日期为空。这是什么意思?

Bob的死亡日期为空。这是什么意思?

一个“合理”的解释可能是Alice的出生日期存在但未知，而Bob的死亡日期不存在(Bob仍然活着)。但是为什么我们会得到不同的答案呢?

另一个问题是:null是一个边缘情况。

null = null? nan = nan吗? 是否inf = inf? +0 = -0吗? +0/0 = -0/0?

答案通常分别是“是”、“否”、“是”、“是”、“否”、“是”。疯狂的“数学家”称NaN为“零”，并说它比较等于自身。SQL将null视为不等于任何东西(因此它们的行为类似于nan)。有人想知道，当您尝试将±∞、±0和nan存储到同一个数据库列中时会发生什么(有253个nan，其中一半是“负的”)。

更糟糕的是，数据库在对待NULL的方式上存在差异，而且大多数数据库并不一致(请参阅SQLite中的NULL处理了解概述)。这太可怕了。

现在是必须讲的故事:

我最近设计了一个(sqlite3)数据库表，有五列a NOT NULL, b, id_a, id_b NOT NULL, timestamp。因为它是一个通用模式，旨在解决相当任意应用程序的通用问题，所以有两个唯一性约束:

UNIQUE(a, b, id_a)
UNIQUE(a, b, id_b)

id_a只存在于与现有应用程序设计的兼容性(部分原因是我还没有提出更好的解决方案)，并没有在新的应用程序中使用。由于NULL在SQL中的工作方式，我可以插入(1,2,NULL, 3, t)和(1,2,NULL, 4, t)而不违反第一个唯一性约束(因为(1,2,NULL) != (1,2, NULL))。

这是因为NULL在大多数数据库的唯一性约束下是如何工作的(可能是为了更容易模拟“现实世界”的情况，例如没有两个人可以有相同的社会安全号码，但并不是所有人都有一个)。

FWIW，如果不首先调用未定义的行为，c++引用不能“指向”null，并且不可能构造带有未初始化引用成员变量的类(如果抛出异常，构造失败)。

旁注:偶尔你可能想要互斥指针(即只有一个可以是非null)，例如在一个假设的iOS类型DialogState = notshow | ShowingActionSheet UIActionSheet | ShowingAlertView UIAlertView |被驳回。相反，我被迫做一些事情，如assert((bool)actionSheet + (bool)alertView == 1)。

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

spec#

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

来自。net背景，我一直认为null是有意义的，它很有用。直到我了解了结构体，以及使用它们是多么容易，避免了大量的样板代码。2009年，托尼·霍尔在伦敦QCon大会上为发明空引用而道歉。引用他的话:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

在程序员身上也可以看到这个问题

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

我不认为这是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.

程序集为我们带来了地址，也称为无类型指针。C语言直接将它们映射为类型化指针，但引入Algol的null作为唯一指针值，与所有类型化指针兼容。在C语言中，null的最大问题是，由于每个指针都可以为空，因此如果不手动检查，就永远无法安全地使用指针。

在高级语言中，使用null是很尴尬的，因为它实际上传达了两个不同的概念:

说明某物没有定义。 告诉别人某件事是可选的。

拥有未定义的变量几乎是无用的，并且无论何时它们出现都会导致未定义的行为。我想每个人都会同意，无论如何都要避免未定义的事情。

第二种情况是可选性，最好显式地提供，例如使用选项类型。

假设我们在一家运输公司，我们需要创建一个应用程序来帮助我们的司机创建时间表。对于每个司机，我们存储了一些信息，例如:他们拥有的驾驶执照和紧急情况下可以拨打的电话号码。

在C语言中我们可以有:

struct PhoneNumber { ... };
struct MotorbikeLicence { ... };
struct CarLicence { ... };
struct TruckLicence { ... };

struct Driver {
  char name[32]; /* Null terminated */
  struct PhoneNumber * emergency_phone_number;
  struct MotorbikeLicence * motorbike_licence;
  struct CarLicence * car_licence;
  struct TruckLicence * truck_licence;
};

正如你所观察到的，在对驱动程序列表的任何处理中，我们都必须检查空指针。编译器不会帮你，程序的安全全靠你的肩膀。

在OCaml中，相同的代码看起来像这样:

type phone_number = { ... }
type motorbike_licence = { ... }
type car_licence = { ... }
type truck_licence = { ... }

type driver = {
  name: string;
  emergency_phone_number: phone_number option;
  motorbike_licence: motorbike_licence option;
  car_licence: car_licence option;
  truck_licence: truck_licence option;
}

现在假设我们想打印所有司机的姓名及其卡车牌照号码。

在C:

#include <stdio.h>

void print_driver_with_truck_licence_number(struct Driver * driver) {
  /* Check may be redundant but better be safe than sorry */
  if (driver != NULL) {
    printf("driver %s has ", driver->name);
    if (driver->truck_licence != NULL) {
      printf("truck licence %04d-%04d-%08d\n",
        driver->truck_licence->area_code
        driver->truck_licence->year
        driver->truck_licence->num_in_year);
    } else {
      printf("no truck licence\n");
    }
  }
}

void print_drivers_with_truck_licence_numbers(struct Driver ** drivers, int nb) {
  if (drivers != NULL && nb >= 0) {
    int i;
    for (i = 0; i < nb; ++i) {
      struct Driver * driver = drivers[i];
      if (driver) {
        print_driver_with_truck_licence_number(driver);
      } else {
        /* Huh ? We got a null inside the array, meaning it probably got
           corrupt somehow, what do we do ? Ignore ? Assert ? */
      }
    }
  } else {
    /* Caller provided us with erroneous input, what do we do ?
       Ignore ? Assert ? */
  }
}

在OCaml中是:

open Printf

(* Here we are guaranteed to have a driver instance *)
let print_driver_with_truck_licence_number driver =
  printf "driver %s has " driver.name;
  match driver.truck_licence with
    | None ->
        printf "no truck licence\n"
    | Some licence ->
        (* Here we are guaranteed to have a licence *)
        printf "truck licence %04d-%04d-%08d\n"
          licence.area_code
          licence.year
          licence.num_in_year

(* Here we are guaranteed to have a valid list of drivers *)
let print_drivers_with_truck_licence_numbers drivers =
  List.iter print_driver_with_truck_licence_number drivers

正如你在这个简单的例子中看到的，在安全版本中没有什么复杂的东西:

这是要简洁。 你得到了更好的保证，根本不需要空检查。 编译器确保您正确地处理了该选项

而在C语言中，你可能只是忘记了一个空检查，然后……

注意:这些代码示例没有编译，但我希望你明白了。

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

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

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

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

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

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

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

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

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

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

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