null - 关于不可为空类型的争论

Question

我一直听到人们谈论不可空引用类型如何解决如此多的错误并使编程变得如此简单。甚至 null 的创建者也称其为他的 billion dollar mistake , 和 Spec#引入了不可为空的类型来解决这个问题。

编辑:忽略我对 Spec# 的评论。我误解了它的工作原理。

编辑 2:我一定是在和错误的人说话，我真的希望有人与之争论:-)

所以我猜，作为少数，我错了，但我不明白为什么这场辩论有任何值(value)。我认为 null 是一个错误查找工具。考虑以下:

class Class { ... }

void main() {
    Class c = nullptr;
    // ... ... ... code ...
    for(int i = 0; i < c.count; ++i) { ... }
}

砰!访问冲突。有人忘记初始化 c .

现在考虑这个:

class Class { ... }

void main() {
    Class c = new Class(); // set to new Class() by default
    // ... ... ... code ...
    for(int i = 0; i < c.count; ++i) { ... }
}

哎呀。循环被悄悄地跳过。追踪问题可能需要一段时间。

如果你的类是空的，代码无论如何都会失败。为什么不让系统告诉您(尽管有点粗鲁)，而不必自己弄清楚？

Answer 1

有点奇怪的是，该线程中标记为“答案”的响应实际上首先突出了 null 的问题，即:

I've also found that most of my NULL pointer errors revolve around functions from forgetting to check the return of the functions of string.h, where NULL is used as an indicator.

如果编译器可以在编译时而不是运行时捕获这些类型的错误，那不是很好吗？

如果您使用过类似 ML 的语言(在某种程度上，SML、OCaml、SML 和 F#)或 Haskell，则引用类型是不可为空的。相反，您通过将其包装为选项类型来表示“空”值。通过这种方式，如果函数可以返回 null 作为合法值，则您实际上更改了函数的返回类型。所以，假设我想从数据库中拉出一个用户:

let findUser username =
    let recordset = executeQuery("select * from users where username = @username")
    if recordset.getCount() > 0 then
        let user = initUser(recordset)
        Some(user)
    else
        None

查找用户类型为 val findUser : string -> user option ，所以函数的返回类型实际上告诉你它可以返回一个空值。要使用代码，您需要处理 Some 和 None 两种情况:

match findUser "Juliet Thunderwitch" with
| Some x -> print_endline "Juliet exists in database"
| None -> print_endline "Juliet not in database"

如果您不处理这两种情况，则代码甚至无法编译。所以类型系统保证你永远不会得到空引用异常，它保证你总是处理空值。如果函数返回 user ，它保证是一个对象的实际实例。了不起。

现在我们在 OP 的示例代码中看到了问题:

class Class { ... }

void main() {
    Class c = new Class(); // set to new Class() by default
    // ... ... ... code ...
    for(int i = 0; i < c.count; ++i) { ... }
}

已初始化和未初始化的对象具有相同的数据类型，您无法区分它们之间的区别。偶尔， null object pattern可能很有用，但上面的代码表明编译器无法确定您是否正确使用了类型。