golang-design / under-the-hood

📚 Go: Under The Hood | Go 语言原本 | https://golang.design/under-the-hood

Home Page:https://golang.design/under-the-hood

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`ch03lang/panic.md`中关于panic捕获的例子,不知是否有人像我一样也理解错过?

l-qing opened this issue · comments

原文内容

从 panic 和 recover 这对关键字的实现上可以看出,可恢复的 panic 必须要 recover 的配合。
而且,这个 recover 必须位于同一 goroutine 的直接调用链上(例如,如果 A 依次调用了 B 和 C,而
B 包含了 recover,而 C 发生了 panic,则这时 B 的 panic 无法恢复 C 的 panic;
又例如 A 调用了 B 而 B 又调用了 C,那么 C 发生 panic 时,如果 A 要求了 recover 则仍然可以恢复),
否则无法对 panic 进行恢复。

https://github.com/golang-design/under-the-hood/blame/e82540ec1e86aa13edb71a7b3f25b61842215a9e/book/zh-cn/part1basic/ch03lang/panic.md#L500

我最开始的错误理解

我以为分号后面的"又例如"仅仅指代调用关系从"A->B A->C"切换为了"A->B->C".
导致最后的"如果 A 要求了 recover 则仍然可以恢复"这句话没明白什么意思.

直到写这个issue的过程中,才反应过来原来分号后面完全是一个新的例子了.

个人拙见

原文中的

例如,如果 A 依次调用了 B 和 C,而 B 包含了 recover,而 C 发生了 panic,则这时 B 的 panic 无法恢复 C 的 panic;
又例如 A 调用了 B 而 B 又调用了 C,那么 C 发生 panic 时,如果 A 要求了 recover 则仍然可以恢复

替换成

例如,如果 A 依次调用了 B 和 C,而 B 包含了 recover,而 C 发生了 panic,则这时 B 的 recover 无法恢复 C 的 panic;
但是,如果 A 调用了 B 而 B 又调用了 C,那么 C 发生 panic 时,这时 B 的 recover 是可以恢复 C 的 panic。

是不是就减少了被误解的可能性了呢?

备注

在写issue的过程中才发现原文中的"则这时 B 的 panic 无法恢复 C 的 panic"好像写错了.
如果后半句不做调整的话,我可以再单独提一个issue去修复该问题.

这里确实存在一个 typo。

例如,如果 A 依次调用了 B 和 C,而 B 包含了 recover,而 C 发生了 panic,则这时 B 的 panic 无法恢复 C 的 panic;

应该被修改为

例如,如果 A 依次调用了 B 和 C,而 B 包含了 recover,而 C 发生了 panic,则这时 B 的 recover 无法恢复 C 的 panic;

对应下面的例子:

func A () {
    B()
    C()
}

func B() {
    defer func () {
        recover() // 无法恢复 panic("C")
    }()

    println("B")
}

func C() {
    panic("C")
}

又例如 A 调用了 B 而 B 又调用了 C,那么 C 发生 panic 时,如果 A 要求了 recover 则仍然可以恢复

旨在表达如下的例子:

func A () {
    defer func () {
        recover() // 可以恢复 panic("C")
    }()

    B()
}

func B() {
    C()
}

func C() {
    panic("C")
}

因此分号后段的文字是正确的表达。

对此,一个可能的修复是:

- 例如,如果 A 依次调用了 B 和 C,而 B 包含了 recover,而 C 发生了 panic,则这时 B 的 panic 无法恢复 C 的 panic;
+ 例如,如果 A 依次调用了 B 和 C,而 B 包含了 recover,而 C 发生了 panic,则这时 B 的 recover 无法恢复 C 的 panic;

不过考虑到文字的表现力不如代码充分,可以在修复中同时附上前面提到的代码。PR welcome。