Question

作为一个新的发烧友，尝试使用错误处理的方式。要清楚 - 我喜欢例外。

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

if err != nil{
      panic(err)
}

深入处理代码中的

并且

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

在客户端连接代码中（每个连接都在goroutine中）。这很好地包装了一切，强行关闭连接（其他延迟火灾），我的服务器继续嗡嗡作响。

但是这感觉非常像投掷/捕获场景 - golang说它不支持。问题

这是稳定的。即恢复恐慌是一件好事持续的生活方式。它不打算只是稍微推迟一个立即关机
我找了一个关于这个主题的讨论，并没有在任何地方找到它 - 任何指针？

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

Answer 1

是的，你可以做你的建议。在标准软件包中有一些情况下使用panic / recover来处理错误。 official Go blog州：

有关恐慌和恢复的真实示例，请参阅json包来自Go标准库。它使用set解码JSON编码的数据递归函数。遇到格式错误的JSON时，解析器调用panic来将堆栈展开到顶级函数调用，这就是从恐慌中恢复并返回一个适当的错误值（见错误＆＃39; ＆＃39; unmarshal＆＃39; decodeState类型的方法 decode.go）。

一些指示：

对正常使用情况使用error。这应该是您的默认设置。
如果使用panic / recover（例如使用递归调用堆栈），您的代码会更清晰，更简单，那么请将其用于特定情况。
永远不要让包裹泄漏。包中使用的恐慌应该在包中恢复并作为错误返回。
从恐慌中恢复是稳定的。不要担心恢复后继续执行。您可以在标准库中看到此类行为，例如使用net/http程序包从处理程序中的panic中恢复，以防止整个http服务器在单个请求进行切换时崩溃。

Answer 2

通常大多数方法都不会出现恐慌，它们会返回错误，并且使用延迟会产生一些开销。

所以是的，它确实有效，但“正确”/“去”方式是返回错误而不是使用恐慌/恢复。

将恐慌/恢复视为throw / catch是错误的

2 个答案: