There are cases like this in chan.go and select.go also, and perhaps error.go as well. In general any panic("string") in non-test code in the runtime is suspect, except for cases like panic("not reached").

The only tricky thing though is that since importing errors or even fmt would result in circular imports and fail, using runtime's errorString is the way to go. However errorString's Error() method prefixes runtime error: before every message.
This will mean that the panics that will now be fixed e.g originally "assignment to entry in nil map" will now be "runtime error: assignment to entry in nil map". If this is deemed as not a compatibility problem, since this code has been in the stdlib for a while since July 2014

I can spin up a CL to fix this.

Should some of these be throw cases, not panic cases? I think most of these
are not recoverable.

On Mon, 28 Mar 2016, 10:01 Minux Ma, notifications@github.com wrote:

we can define a new string type that implements
error in runtime for those cases.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#14965 (comment)

@minux we already have errorString

If we defined a new string type for just these cases, it might look out of place and moreover there are already usages of errorString in runtime so that might look confusing when the only difference between the two different error strings' Error() results is the prefix "runtime: ".

@davecheney IMO I think we could do this in a separate issue as that changes the behavior as opposed to first fixing this issue and conforming to the docs that say panics from the runtime should be with Error's as defined here https://golang.org/ref/spec#Run_time_panics.

@minux thanks. In this case, we have no other option then but to define a new string type.
I just wanted to get clarification that we were on the same page.

CL https://golang.org/cl/21214 mentions this issue.