중첩된 `defer`가 Go에서 패닉을 복구하지 못하는 이유는 무엇입니까?

중첩된 지연 함수에서 복구가 비효율적인 이유 공개

Golang에서 Recover()는 예외 처리 및 예방을 위한 중요한 메커니즘 역할을 합니다. 패닉의 확산. 그러나 중첩된 지연 함수 내에서 Recover()를 사용할 때 흥미로운 관찰이 발생합니다. 예상과는 달리 중첩된 지연이 있음에도 불구하고 패닉이 계속 발생할 수 있습니다.

이 예외를 설명하기 위해 다음 코드를 고려하십시오.

package main

import "fmt"

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

func main() {
    // Direct deferred call to recover()
    defer printRecover()

    panic("OMG!")
}

이 코드가 실행되면 의도한 대로 작동합니다.

Recovered: OMG!

그러나 printRecover()를 중첩된 deferred 안에 포함하면 함수:

package main

import "fmt"

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

func main() {
    // Nested deferred call to recover()
    defer func() {
        printRecover()
    }()

    panic("OMG!")
}

결과 변경:

Recovered: <nil>
panic: OMG!

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

복귀()의 고유한 동작에서 불일치가 발생합니다. Go 사양에 따라, Recover():

• nil을 반환하는 경우:

  • 패닉 인수가 nil
  • goroutine이 그렇지 않은 경우 당황
  • recover()가 지연된 개체에 의해 직접 호출되지 않았습니다. function

중첩된 지연된 경우, 복구()는 가장 바깥쪽의 지연된 함수에 의해 직접 호출되지 않고 중첩된 함수에 의해 호출되었습니다. 결과적으로 nil을 반환하고 패닉을 처리하지 않은 상태로 둡니다.

이 중요한 차이점은 Golang에서 효과적인 패닉 복구를 보장하기 위해 지연된 함수 내에서 Recover()를 직접 사용하는 것의 중요성을 강조합니다.

위 내용은 중첩된 `defer`가 Go에서 패닉을 복구하지 못하는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!