return nil, nil 不是惯用的 go 吗？

Question

如果我们GO中有如下方法：

GetCustomer(id string) (*Customer, error)

数据库中可能不存在给定 ID 的客户。当找不到客户时，代码可以

return nil, nil

这在 Go 中被认为是不好的编码实践吗？或者惯用的 Go 代码会是什么样子

 return nil, errCustomerNotFound

我看到第二种方法的问题是你最终会检查这个特定的错误并单独处理它。

Go 源代码或库中是否有出现这种情况的示例，并且其中一种方法是首选？

更新

如果

return nil, nil

被认为不惯用。我想知道为什么在这种情况下是这样？由于 *Customer 是一个指针，我想返回 nil 来表示没有值

Answer 1

return nil, nil

在您的情况下是否惯用取决于

nil

*Customer

是否是有用的值。

如果

nil

的

*Customer

值在代码中是正常有用的值，则返回该值（没有错误）是有意义的。

尽管 nil 结构指针很少有用——在大多数情况下，仅此一点就可以被认为是不惯用的。

应遵循的规则：

每个函数都应始终返回一组有用的值。

在你的情况下，当你返回一个结构指针和一个错误时，人们可以合理地假设其中最多有一个为零。

使用 nil 结构指针来指示值的缺失可以是惯用的，但不能与错误一起使用。如果您的函数只能有一个“未找到”错误条件，您可以选择仅返回单个值（可能为 nil）的函数，或者您可以选择返回指示存在而不是错误的布尔值。

但是，当还包含错误时，返回 nil 表示“未找到”，充其量是令人困惑的，因为它违反了 最小惊讶原则。

Answer 2

它因情况而异，有时 nil 值在空返回频繁且作为零值有用的情况下很有用，此时代码的其余部分可以很好地处理它们。

如果 nil 值不常见且难以在测试中捕获，那么您根本不应该返回它们。另外，非常不鼓励返回一个 nil 通道，或者任何导致 nil 指针与 nil 接口混淆的东西。

Nil 通道将阻塞所有操作而不是导致错误，通常它们表明您应该公开将读取或写入通道（或包装发送/读取的回调）传递给函数的 API，而不是从函数返回通道，或者使用上下文或其他包装结构来代替。