当前位置: 首页 > 知识库问答 >
问题:

把恐慌/恢复当作扔/抓是错的吗

养淇
2023-03-14

作为一个新的围棋爱好者,试图使用围棋的错误处理方式。明确地说--我喜欢例外。

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

if err != nil{
      panic(err)
}

在深层处理代码中

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

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

共有1个答案

贺方伟
2023-03-14

是的,你可以按你的建议去做。在标准包中,有些情况下使用panic/recover来处理错误。官方围棋博客称:

有关panic和recover的实际示例,请参见Go标准库中的json包。它使用一组递归函数对JSON编码的数据进行解码。当遇到格式错误的JSON时,解析器调用panic将堆栈解压缩到顶层函数调用,顶层函数调用从panic中恢复并返回适当的错误值(请参见decode.go中decodeState类型的'error'和'unmarshal'方法)。

一些指针:

    null
 类似资料:
  • 问题内容: 在defer函数中,我想查看一次恢复调用是否会产生非nil值(不恢复) 可能吗? 问题答案: 那确切的事情是不可能的。您可能只想重新恐慌,就像在其他语言中重新引发异常一样。

  • 我试图从我的程序中创建的go例程中捕捉崩溃/恐慌,以便将它们发送到我的崩溃错误报告服务器(如Sentry/Raygun) 例如, 做这件事的惯用方法是什么?

  • 我有以下代码: 在错误处理和从恐慌中恢复方面,他们的东西是我遗漏的。我是新来的,所以想要一些建议。

  • 问题内容: 我曾经认为,如果goroutine中的恐慌的调用者在恐慌之前完成,它将使其终止程序(延迟恢复没有任何帮助,因为此时还没有发生恐慌), 直到我尝试以下代码: 我发现无论调用者函数完成与否,如果goroutines开始恐慌,调用者的延迟恢复机制将无济于事。整个程序仍然无效。 所以为什么?理论上,调用者功能仍在运行。当出现紧急情况时,调用者的延迟功能应起作用(包括恢复)。 问题答案: 该规范

  • 我正在学习围棋,我试图理解如何正确处理来自外部包的恐慌。 调用doFoo方法会使服务器崩溃,我认为这是正确的行为,因为应用程序现在处于受损状态。最好是崩溃,然后通过某个负载均衡器将后续请求转发到不同的进程。但是,我的api服务器可能还在为其他客户机服务,它可能在维护websockets,而且我可能还想在这里返回一个500错误。 来自nodejs,我习惯了处理未捕获的同步异常和处理未捕获的异步异常的