我有一个带有 SPA 的 GoLang API 来使用它。我对我的 API 中的错误所做的是返回它们，直到我测试是否存在以前函数的错误的处理程序。如果有错误，我将它放在响应主体中，将状态代码设置为 400 或 500，然后返回响应

在处理函数中，为了能够向客户端创建清晰的消息，我需要知道返回了什么样的错误，我该怎么做？

我知道错误类型，但我读到了 Dave Cheney 的建议，即只返回错误和消息(或换句话说将它们包装起来)。

但是如果API调用中可能会出现这么多错误，那是不是意味着在返回响应之前，我需要将它们都检查一遍才能知道我应该返回什么消息？

最佳答案

首先要说的错误就是因为有一个错误接口(interface)

type error interface {
    Error() string
}

并不意味着从任何给定方法返回的错误可以仅附加该方法/信息。

一种常见的方法是定义自己的错误接口(interface):

type myError interface {
    error // embeds the standard error interface
    OtherMethod() string // can define own methods here
}

在编写方法和函数时，返回错误而不是myError是非常重要，否则您将该方法耦合到您的错误实现中，并且以后会给自己带来依赖性噩梦。

现在我们已经决定我们可以从错误中返回额外的信息，使用我们自己的错误接口(interface)，您有 3 个主要选择。

1. 哨兵错误
2. 错误失败类型
3. 行为错误

哨兵错误

哨兵错误是定义为包级变量的错误值，被导出并允许比较以检查错误。

package myPackage

var ErrConnectionFailed = errors.New("connection failed")

func Connect() error {
    // trimmed ...
    return ErrConnectionFailed
}

此示例的使用者可以使用连接功能:

if err := myPackage.Connect(); err == myPackage.ErrConnectionFailed {
    // handle connection failed state
}

你可以做一个比较来检查返回的错误是否等于包的哨兵错误。缺点是使用 errors.New("connection failed") 创建的任何错误都将是相等的，并且不仅仅是来自 myPackage 的错误。

错误失败类型

比哨兵错误稍微好一点的是错误失败类型。 我们已经看到您可以定义自己的错误接口(interface)，如果我们现在说我们的错误接口(interface):

type MyError interface {
    error
    Failure() string
} 

type Err struct {
    failure string
}

func (e *Err) Error() string {
    // implement standard error
}

func (e *Err) Failure() string {
    return e.failure
}

const ConnFailed = "connection failed"

err := &Err{failure: ConnFailed}

在消费者代码中你可以得到一个错误，检查它是否实现了 MyError 然后用它做一些事情。

err := myPackage.Connect()

if myErr, ok := err.(myPackage.MyError); ok {
    // here you know err is a MyError
    if myErr.Failure() == myPackage.ConnFailed {
        // handle connection failed, could also use a switch instead of if
    }
}

现在您了解了导致错误的原因，这很好。但你真的关心原因是什么吗？或者你真的只关心你想做什么来处理那个错误。

这是行为错误的好地方。

行为错误

这类似于定义您自己的错误类型，但您定义的是报告有关该错误信息的方法。鉴于上面的示例，您真的关心连接失败，还是只关心是否可以重试或是否需要再次出错调用堆栈？

package myPackage

// this interface could report if the error
// is temporary and if you could retry it
type tempErr interface {
    Temporary() bool
}

func (e *Err) Temporary() bool {
    // return if the error is temporary or not
}

现在在消费者中(注意您不需要使用 myPackage.tempErr)，如果错误是暂时的并处理重试情况，您可以使用类型断言进行测试:

err := myPackage.Connect()

if tmp, ok := err.(interface { Temporary() bool }); ok && tmp.Temporary() {
    // the error is temporary and you can retry the connection
}

要回答这个问题，如果没有您尝试实现的服务的具体细节，很难说清楚。但作为广泛的建议，我会尽可能多地尝试使用 3 个示例中的最后一个。

如果您的服务的消费者向您发送一些无效的输入:

err := doThing(...)

if inv, ok := err.(interface { Invalid() bool }); ok && inv.Invalid() {
    // input is invalid, return 400 bad request status code etc.
}

如果您想将特定消息返回给消费者，您可以将其作为您的错误类型的方法。警告:这会让您的包知道它们正在 web 服务等中使用。

err := doThing(...)

if msg, ok := err.(interface { ResponseMsg() string }); ok {
    // write the message to the http response
    io.WriteString(response, msg.ResponseMsg())
}

TL;DR 您需要处理所有情况，但您可以创建错误类型，使代码更易于使用!

关于rest - 如何确定我应该从 golang API 返回哪种错误消息？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50898622/