在 Golang 中,没有恢复的 panic 会使进程崩溃,所以我最终将以下代码片段放在每个函数的开头:defer func() { if err := recover(); err != nil { fmt.Println(err) }}()只是为了防止我的程序崩溃。现在我想知道,这真的是要走的路吗?因为我觉得到处放同样的代码看起来有点奇怪。在我看来,Java 方式将异常冒泡到调用函数,直到主函数是控制异常/恐慌的更好方法。我知道这是 Go 的设计,但是像 Go 一样立即使进程崩溃有什么好处?
2 回答
海绵宝宝撒
TA贡献1809条经验 获得超8个赞
如果您确切地知道原因,您应该只从恐慌中恢复过来。Go 程序在本质上会在两种情况下发生恐慌:
程序逻辑错误(例如 nil 指针取消引用或越界数组或切片访问)
panic(...)
来自您的代码或您的代码调用的代码的故意恐慌(称为 using )
在第一种情况下,崩溃是合适的,因为这意味着您的程序已进入错误状态,不应继续执行。在第二种情况下,您应该只在预期的情况下从恐慌中恢复过来。解释这一点的最好方法就是说它非常罕见,如果您看到它,您就会知道这种情况。我几乎可以肯定,无论您正在编写什么代码,都不需要从恐慌中恢复过来。
凤凰求蛊
TA贡献1825条经验 获得超4个赞
通常,即使有例外,您也会在“FaultBarrier”处捕获它们。它通常是所有新线程产生的地方。重点是捕捉和记录意外的失败。
在 Go 中,您对所有预期的失败使用返回值。您工作的框架通常会有一个故障屏障来捕获会话(即:通常是一个 http 事务)并记录问题。我看到恢复发生的唯一其他地方是非幂等关闭函数之类的东西。如果您无法判断某些东西是否已经关闭但知道它必须关闭,那么您最终可能会进行恢复,以便忽略第二次关闭恐慌,而不是使您所做的所有事情都失败直到FaultBarrier。
- 2 回答
- 0 关注
- 256 浏览
添加回答
举报
0/150
提交
取消