为什么 Go panic() 将 interface{} 而不是 ...interface{}

Question

我注意到panic需要interface{}作为一个参数，而fmt.Print和喜欢拿...interface{}。也panic带上不是更方便...interface{}吗？为什么 Go 作者定义panic为func panic(v interface{})而不是func panic(v ...interface{})（就像他们对 所做的那样fmt）？

Answer 1

panic一开始并没有只接受一个论点。

您可以将单参数实现追溯到 2010 年 3 月 30 日：

commit 01eaf78 gc: add panicand recover（在运行时仍未实现）

主要的语义变化是强制单一参数恐慌。

该规范在提交 5bb29fb 中得到修复，提交 00f9f0c说明了在多个参数之前恐慌是如何发生的：

src/pkg/bufio/bufio.go

b, err := NewWriterSize(wr, defaultBufSize)

if err != nil {

    // cannot happen - defaultBufSize is valid size

    - panic("bufio: NewWriter: ", err.String())

    + panic(err)

}

这遵循了2010 年 3 月 25 日的提案：

我们不想鼓励将在 Java 等语言中出现的错误和异常混为一谈。

相反，这个提议对 defer 的定义和几个运行时函数进行了轻微的更改，以提供一种处理真正异常情况的干净机制。

在恐慌期间，如果延迟的函数调用调用recover，recover 将返回传递给恐慌的值并停止恐慌。

在任何其他时间，或在延迟调用所调用的函数内部，recover 返回 nil。

停止恐慌后，延迟调用可以使用新参数或相同参数进行恐慌，以继续恐慌。

或者，延迟调用可能会编辑其外部函数的返回值，可能会返回错误。

在这些不同的场景中，处理一个要传递的值似乎比处理可变数量的参数更容易（尤其是在 C 中实现recover时）。