Golang Defer 関数はパニック シーケンスを終了せずに新しいパニックをトリガーできますか?

遅延関数内でのパニックは、特に既存のパニック中に許容されますか?

次のコード スニペットを考慮してください:

func sub(){
    defer func (){
        panic(2)
    }()
    panic(1)
}

func main(){
    defer func(){
        x:=recover()
        println(x.(int));
    }()
    sub()
}

これを実行するときコードを見ると、最初の Panic(1) が 2 番目の Panic(2) に置き換えられているようです。

この方法で続行することは許可されますか、それとも、内部でパニックを引き起こす可能性のある Golang 関数を呼び出すことは許可されますか? defer function?

はい、許容されます。 defer 関数によるパニックは、新しい状況でも特殊な状況でもありません。これは、単にパニック シーケンスが継続することを示しているだけです。

提供されたコード例は、この許容性を示し、defer 関数から呼び出された Panic() であっても、recover() の「より高い」レベルの呼び出しによってどのようにキャッチされるかを示しています。 .

Golang 仕様では、遅延関数の実行中にパニックが発生した場合、回復関数がパニックを捕捉せずに panic() を実行すると、パニック シーケンスは終了しないと規定されています。

さらに、他のすべての遅延関数は、遅延関数内で panic() が呼び出された場合でも実行されます。ただし、遅延関数内に回復関数のないパニック() は、既存のパニックを「上書き」するのではなく「ラップ」します。

たとえば、次のコードを考えてみましょう。

func main() {
    defer func() {
        fmt.Println("Checkpoint 1")
        panic(1)
    }()
    defer func() {
        fmt.Println("Checkpoint 2")
        panic(2)
    }()
    panic(999)
}

出力:

Checkpoint 2
Checkpoint 1
panic: 999
    panic: 2
    panic: 1

すべての遅延関数が Panic() を呼び出しても、それらはすべて実行され、結果として生じるパニック シーケンスには、各 Panic() 呼び出しに渡された値が表示されます。

遅延関数内でrecover()が呼び出されると、最終的な出力には次の「回復された」情報も表示されます:

defer func() {
    recover()
    fmt.Println("Checkpoint 1")
    panic(1)
}()
defer func() {
    recover()
    fmt.Println("Checkpoint 2")
    panic(2)
}()

出力:

Checkpoint 2
Checkpoint 1
panic: 999 [recovered]
    panic: 2 [recovered]
    panic: 1

以上がGolang Defer 関数はパニック シーケンスを終了せずに新しいパニックをトリガーできますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。