go - 将 panic/recover 视为 throw/catch 是错误的吗

Question

作为一名尝试使用 go 错误处理方式的新 go 爱好者发言。明确一点——我喜欢异常(exception)。

我有一个服务器接受一个连接，处理一组请求并回复它们。我发现我可以做到

if err != nil{
      panic(err)
}

在深层次处理代码

有

defer func() {
        if err := recover(); err != nil {
            log.Printf("%s: %s", err, debug.Stack()) // line 20
        }
    }()

在客户端连接代码中(每个连接都在一个 goroutine 中)。这很好地包装了所有内容，强行关闭了连接(其他延迟触发)并且我的服务器继续嗡嗡作响。

但这感觉很像抛/接场景——golang 声明它不支持。问题

• 稳定吗？即 recover panic 是一件可以做的事情持续的生活方式。它不打算只是稍微推迟立即关闭
• 我查找了有关该主题的讨论，但没有在任何地方找到它 - 有任何指示吗？

我觉得答案是“是的，它有效”并且可以在您自己的代码中使用，但是 panic 不应该被用于更广泛使用的库使用。库的标准和礼貌方式是通过错误返回

Answer 1

是的，你可以按照你的建议去做。在标准包中的某些情况下，panic/recover 用于处理错误。 official Go blog状态:

For a real-world example of panic and recover, see the json package from the Go standard library. It decodes JSON-encoded data with a set of recursive functions. When malformed JSON is encountered, the parser calls panic to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value (see the 'error' and 'unmarshal' methods of the decodeState type in decode.go).

一些提示:

• 对您的正常用例使用error。这应该是您的默认值。
• 如果通过使用 panic/recover(例如使用递归调用堆栈)您的代码会变得更清晰和更简单，那么请将其用于特定情况。
• 永远不要让包泄漏 panic 。包内使用的 panic 应在包内恢复并作为错误返回。
• 从 panic 中恢复是稳定的。不要担心恢复后继续执行。您可以在标准库中看到这样的行为，例如 net/http 包，它从处理程序中的 panic 中恢复，以防止整个 http 服务器在单个请求出现 panic 时崩溃。