Go의 중첩된 지연 함수에서 `recover()`가 작동하지 않는 이유는 무엇입니까?

내포된 지연 함수에서 Recover()가 실패하는 이유

다음 Golang 코드를 고려하세요.

package main

import "fmt"

func printRecover() {
    r := recover()
    fmt.Println("Recovered:", r)
}

func main() {
    defer printRecover()

    panic("OMG!")
}

이 간단한 프로그램은 성공적으로 패닉을 일으키고 복구합니다. 다음 출력:

Recovered: OMG!

그러나 코드를 수정하면 printRecover()를 다른 지연된 함수로 래핑하면 다른 결과가 발생합니다.

package main

import "fmt"

func printRecover() {
    r := recover()
    fmt.Println("Recovered:", r)
}

func main() {
    defer func() {
        printRecover()
    }()

    panic("OMG!")
}

이 경우 패닉이 복구되지 않아 프로그램이 충돌하게 됩니다.

Recovered: <nil>
panic: OMG!

goroutine 1 [running]:
main.main()
    /tmp/sandbox898315096/main.go:15 +0x60

이 동작에 대한 설명은 Golang에서 Recover()가 작동하는 방식에 있습니다. 언어 사양에 따르면:

The return value of recover is nil if any of the following conditions holds:

- panic's argument was nil;
- the goroutine is not panicking;
- recover was not called directly by a deferred function.

첫 번째 예에서는 복구()가 지연된 함수에 의해 직접 호출되므로 패닉 인수를 성공적으로 검색합니다. 그러나 두 번째 예에서는 복구()가 지연된 함수에 의해 직접 호출되는 것이 아니라 지연된 함수에 의해 자체적으로 호출된 함수에 의해 호출됩니다. 결과적으로 Recover()는 nil을 반환하고 패닉은 복구되지 않습니다.

위 내용은 Go의 중첩된 지연 함수에서 `recover()`가 작동하지 않는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!