在 Go 中现有的恐慌期间，你可以在 Defer 函数内部发生恐慌吗？

在 Defer 函数内部出现 Panic 是否可以接受，特别是当程序已经 Panicking 时？

在给定的 Go 代码片段中，在 sub( ） 功能。 sub() 内的延迟函数随后再次出现恐慌，并具有不同的值。问题是，是否允许在 defer 函数内发生恐慌，特别是当程序已经发生恐慌时？

解释

是的，在 defer 函数内发生恐慌是可以接受的，即使是在现有的恐慌。延迟功能引起的恐慌不会启动独特或异常的状态；它只是延长了恐慌序列。

提供的代码示例演示了延迟函数引起的恐慌是无害的，甚至允许在更高级别使用recover()进行恢复。

技术细节

根据Go规范关于处理恐慌：

“如果同一个goroutine上的函数发生恐慌，则延迟函数将以与延迟相同的顺序运行，最外面的延迟函数（最后调用的函数）首先运行，如果任何延迟函数调用recover并且在goroutine中的任何地方发生恐慌，则传递给recover的值将是该值。传递给对恐慌的初始调用。”

注意事项

虽然允许在 defer 函数内发生恐慌，但请务必注意即：

• 无论是否出现恐慌，所有延迟函数仍将执行。
• 延迟函数内没有相应的恢复（）调用的恐慌将“包装”当前恐慌并包括它出现在最终的恐慌序列中。

示例

以下示例说明了这一点行为：

<code class="go">func main() {
    defer func() { fmt.Println("Checkpoint 1"); panic(1) }()
    defer func() { fmt.Println("Checkpoint 2"); panic(2) }()
    panic(999)
}</code>

输出：

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

所有延迟函数都会执行，传递给所有panic()调用的值都包含在最终的panic序列中。

结论

延迟函数内部的恐慌，即使是在现有的恐慌期间，在 Go 中也是可以接受的。然而，重要的是要了解延迟函数执行的顺序和后果，并适当地使用recover()来处理恐慌。

以上是在 Go 中现有的恐慌期间，你可以在 Defer 函数内部发生恐慌吗？的详细内容。更多信息请关注PHP中文网其他相关文章！