I noticed panic takes interface{} as an argument, while fmt.Print and the likes take ...interface{}. Wouldn't it be more convenient if panic took ...interface{} as well?
Why did the Go authors define panic as func panic(v interface{}) rather than func panic(v ...interface{}) (like they did with fmt)?
分享 panic didn't take just one argument at first.
You can trace back the one argument implementation back to 30th March 2010:
commit 01eaf78 gc: add panic and recover (still unimplemented in runtime)
main semantic change is to enforce single argument to panic.
The spec is fixed in commit 5bb29fb, and commit 00f9f0c illustrates how panic could took before multiple arguments:
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)
}
That follows a proposal from March 25th, 2010:
We don't want to encourage the conflation of errors and exceptions that occur in languages such as Java.
Instead, this proposal uses a slight change to the definition of defer and a couple of runtime functions to provide a clean mechanism for handling truly exceptional conditions.
During panicking, if a deferred function invocation calls recover, recover returns the value passed to panic and stops the panicking.
At any other time, or inside functions called by the deferred call, recover returns nil.
After stopping the panicking, a deferred call can panic with a new argument, or the same one, to continue panicking.
Alternately, the deferred call might edit the return values for its outer function, perhaps returning an error.
In those various scenario, dealing with one value to pass around seems easier than dealing with an variable number of arguments (especially when it comes to implement recover in C).
分享
