proposal: runtime: provide a way to format output in unhandled panics

[mitar]

Background

When code calls panic(err) and panic is not handled (recovered) it aborts the whole program while printing the panic value and goroutine stack traces. If the panic value implements the error interface, code currently calls its Error method and prints it out.

Proposal

I propose that the code there first checks for the following interface:

type panicError interface {
    error
    PanicError() string
}

And if the value implements this interface, PanicError is called instead of Error to obtain the string to print out.

Discussion

I am the author of the gitlab.com/tozd/go/errors, a modern drop-in replacement for github.com/pkg/errors which enables errors to be annotated with stack traces and structured details. I noticed that it is pretty common for people to pass error values to panic. But the issue is that errors with additional optional information do not have any way to output that information when unhanded panic occurs. For example, errors contain a stack trace where they happened but that stack trace is not printed out, nor is available among stack traces printed out by runtime itself (the error might have happened at a completely different place than where panic is called). Errors do print that additional information when using fmt.Printf, but that is not used by the runtime.

So I suggest that runtime checks for the above interface first, and if it exists, calls it, giving errors an option to provide additional useful information for debugging. The cost of doing this should be minimal (unhandled panics are rare, it is one extra type case in the existing type switch).

Alternatives

Errors could add all extra information to output from Error() but generally none of libraries I have seen is doing that. The reason is probably simple: such strings with extra information are hard to combine while Error() strings generally stay oneliners (except when using errors.Join).