go - 在 Golang 中处理 nil 和错误的惯用方法是什么？

Question

我有 2 个函数:

func sampleFunction () {
    u, err := findDog(1)
    if err != nil {
        // We couldn't find the dog, print a message.
        fmt.Println(err)
        // Custom error types.
        if _, ok := err.(*dneError); ok {
            fmt.Println("Custom dog dne error for the end-user here.")
        }
    } else {
        // Do something with u.
        u.doSomething() // Is this idiomatic in Go?
                        // Should we explicility check for u != nil?
                        // Or does the if check above need to return?
                        // (even if I would like the function to be longer)

    }
}

// findDog returns a dog with a given ID. If not found, returns an error.
func findDog(id int) (*models.Dog, error) {
    found, err := models.FindDog(id)
    // Is this return scheme/flow too brittle?
    if err != nil {
        return nil, &dneError{fmt.Sprintf("Dog %d does not exist in the" +
            "database: %s", id, err.Error())}
    }
    return found, nil
}

我只想确保正确处理错误和 nils，所以我的 2 个主要问题是:

1. 在 findDog 中，我是否在两种情况下都适本地返回了 nil？

2. 在 sampleFunction 中，不显式检查 u != nil 是惯用的，还是我完全错误地这样做了？

我的目标是在需要时向程序员正确显示错误/问题，并在用户需要时向用户显示错误/问题，同时遵守惯用标准。感谢您的宝贵时间。

Answer 1

是的，这是地道的 Go。因为错误是预先处理的，所以错误意味着失败并且结果是 nil，或者例如也许是一个没有任何用处的部分写入的缓冲区。

附言我还有一个建议可以使事情更加地道。这个成语有点像“缩进错误 block ，而不是代码”。您在 sampleFunction 中特别有一个 if/else，但在大多数错误检查情况下(不是全部)您处理它并返回，然后跳过 else 并且流程继续。为什么在不需要时缩进？这具有使长函数易于阅读的效果，因为函数的预期流程可以从上到下阅读，而不必在 if/else block 之间来回跳转。至少在很多场合。

我修改了对某人存储库的拉取请求，因为我有一个 if/else，其中 if with return 就足够了。

编辑所以我的回答让我有点困扰，现在我记得为什么了。非 nil error 返回通常是惯用的，表示其他返回值无用，但确实有异常(exception)。 一定要检查个别文档。

作为具体示例，请参见 bytes.Buffer.ReadBytes

If ReadBytes encounters an error before finding a delimiter, it returns the data read before the error and the error itself (often io.EOF).