Go의 하위 고루틴에서 호출자 함수가 패닉을 복구할 수 있나요?

Go에서 Child Goroutine Panics 복구

최근 프로그래밍 작업 중에 근본적인 가정에 도전했습니다. 어린이 고루틴의 패닉에서 회복하세요. 일반적인 통념에도 불구하고, 호출자의 지연된 복구 메커니즘은 하위 고루틴이 패닉에 빠졌을 때 전체 프로그램의 종료를 막지 못하는 것으로 나타났습니다.

이 혼란스러운 동작을 설명하기 위해 다음 코드를 고려하십시오.

<code class="go">func fun1() {
    fmt.Println("fun1 started")
    defer func() {
        if err := recover(); err != nil {
            fmt.Println("recover in func1")
        }
    }()

    go fun2()

    time.Sleep(10 * time.Second) // wait for the boom!
    fmt.Println("fun1 ended")
}

func fun2() {
    fmt.Println("fun2 started")

    time.Sleep(5 * time.Second)
    panic("fun2 booom!")

    fmt.Println("fun2 ended")
}</code>

흥미롭게도 fun1이 fun2의 패닉 전후에 종료되는지 여부에 관계없이 fun1의 지연된 복구 메커니즘은 효과가 없는 것으로 판명되어 프로그램이 즉시 중단됩니다.

실패

Go 사양은 이러한 특이한 동작에 대해 명확성을 제공합니다.

함수 F를 실행하는 동안 패닉에 대한 명시적인 호출 또는 런타임 패닉이 F의 실행을 종료합니다. F에 의해 연기된 함수는 평소대로 실행됩니다. 다음으로, F의 호출자가 실행한 모든 지연된 함수가 실행되고, 실행 고루틴의 최상위 함수에 의해 지연된 함수까지 실행됩니다. 그 시점에서 프로그램이 종료됩니다. 패닉에 대한 인수 값을 포함하여 오류 조건이 보고됩니다.

이 경우 fun2는 해당 고루틴에서 실행되는 최상위 함수를 나타냅니다. fun2에는 복구 메커니즘이 없기 때문에 프로그램은 fun1 또는 이전 버전의 지연된 복구 시도를 무시하고 패닉 상태에서 종료됩니다.

이 동작은 중요한 차이점을 강조합니다. 고루틴은 다음에서 발생하는 패닉에서 복구할 수 없습니다. 별도의 고루틴. 결과적으로 fun2의 패닉으로 인해 goroutine과 후속 복구 노력이 효과적으로 종료되므로 fun1의 지연된 복구는 쓸모가 없게 됩니다.

위 내용은 Go의 하위 고루틴에서 호출자 함수가 패닉을 복구할 수 있나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!