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

惊慌失措,从一个包裹中恢复过来

贡威
2023-03-14

我试图弄清楚panic()recover()是如何工作的..

package log

import (
    "fmt"
)

func Recover() {
    fmt.Println("Recovering!")
    if err := recover(); err != nil {
        fmt.Println("Error message recovered!")
    }
}
package main

import (
    "fmt"
    log "www/pkg/log"
)

func main() {
    defer func() {
        log.Recover()
    }()

    panic("Fake error!")
}
Recovering!
panic: Fake error!

为什么错误消息被恢复!从未打印?

共有1个答案

鲜于浩淼
2023-03-14

应用程序必须直接从deferred函数调用recover来处理恐慌。

规范谈到了调用recover的延迟函数:

假设一个函数G推迟了调用recover的函数D,并且在执行G的同一goroutine上的一个函数中发生了一个panic。当延迟函数的运行达到D时,D的恢复调用的返回值将是传递给panic调用的值。

    null
 类似资料:
  • 问题内容: 在Golang中,没有恢复的紧急情况会使进程崩溃,因此我最终将以下代码片段放在每个函数的开头: 只是为了防止我的程序崩溃。现在我想知道,这真的是要走的路吗?因为我认为到处都放置相同的代码看起来有些奇怪。 在我看来,以Java的方式将异常冒泡到调用函数之前,直到main函数是控制异常/恐慌的更好方法为止。我了解这是Go的设计,但是像Go一样立即使过程崩溃的好处是什么? 问题答案: 如果您

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

  • 我曾经认为goroutine中的恐慌会杀死程序,如果它的调用者在恐慌之前完成(延迟恢复没有任何帮助,因为在这一点上还没有恐慌发生), 直到我尝试下面的代码: 我发现无论调用方函数是否完成,如果goroutines开始恐慌,调用方的延迟恢复机制都没有帮助。整个程序还是死气沉沉的。

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

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