go - 在 Go 中返回 nil 或自定义错误

Question

当在 Go 中使用自定义 Error 类型时(使用额外的字段来捕获一些细节)，当尝试返回 nil 作为该类型的值时，我得到编译错误像 cannot convert nil to type DetailedError 或像 cannot use nil as type DetailedError in return argument，代码看起来像这样:

type DetailedError struct {
    x, y int
}

func (e DetailedError) Error() string {
    return fmt.Sprintf("Error occured at (%s,%s)", e.x, e.y)
}

func foo(answer, x, y int) (int, DetailedError) {
    if answer == 42 {
        return 100, nil  //!! cannot use nil as type DetailedError in return argument
    }
    return 0, DetailedError{x: x, y: y}
}

(完整片段:https://play.golang.org/p/4i6bmAIbRg)

解决这个问题的惯用方法是什么？(或者任何可行的方法...)

我实际上需要额外的错误字段，因为我有详细的错误消息，这些错误消息是由复杂的逻辑从更简单的错误等构造的，如果我只想回退到“字符串错误”，我基本上必须解析 将这些字符串分解并根据它们进行逻辑处理等等，这看起来真的很难看(我的意思是，为什么要序列化为你知道稍后需要反序列化的字符串信息...)

Answer 1

不要使用DetailedError作为返回类型，总是使用error:

func foo(answer, x, y int) (int, error) {
    if answer == 42 {
        return 100, nil  //!! cannot use nil as type DetailedError in return argument
    }
    return 0, DetailedError{x: x, y: y}
}

您的 DetailedError 类型满足 error 接口(interface)这一事实足以让这项工作成功。然后，在您的调用方中，如果您关心额外的字段，请使用类型断言:

value, err := foo(...)
if err != nil {
    if detailedErr, ok := err.(DetailedError); ok {
        // Do something with the detailed error values
    } else {
        // It's some other error type, behave accordingly
    }
}

不返回DetailedError的原因:

现在这似乎无关紧要，但将来您的代码可能会扩展以包含额外的错误检查:

func foo(answer, x, y int) (int, error) {
    cache, err := fetchFromCache(answer, x, y)
    if err != nil {
        return 0, fmt.Errorf("Failed to read cache: %s", err)
    }
    // ... 
}

其他错误类型不会是 DetailedError 类型，因此您必须返回error。

此外，您的方法可能会被其他不知道或不关心 DetailedError 类型的调用者使用:

func fooWrapper(answer, x, y int) (int, error) {
    // Do something before calling foo
    result, err := foo(answer, x, y)
    if err != nil {
        return 0, err
    }
    // Do something after calling foo
    return result, nil
}

期望函数的每个调用者都理解自定义错误类型是不合理的——这正是 Go 中存在接口(interface)，尤其是 error 接口(interface)的原因。

利用这一点，不要规避它。

即使您的代码永远不会更改，为每个函数或用例设置新的自定义错误类型也是不可持续的，并且会使您的代码不可读且无法推理。