go: proposal: runtime: add mechanism to configure format used to write out unhandled panics
What version of Go are you using (go version)?
go version go1.14.4 linux/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/mitar/.cache/go-build" GOENV="/home/mitar/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/mitar/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build926066688=/tmp/go-build -gno-record-gcc-switches"
What did you do?
I am using logrus to log messages encoded as JSON objects to stderr.
What did you expect to see?
When unhanded panic happens, anywhere in the program, 3rd party libraries, and goroutines, I would like that panic is logged as JSON object as well, so that JSON parsing does not fail on that output from the program.
What did you see instead?
Panic message is not JSON so parsing of it fails when storing logs into storage expecting JSON. Moreover, one cannot then search over stored messages to obtain information about a particular panic: because it has not been stored.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 20 (19 by maintainers)
Multiple formats seems like a mistake - why put that code into every single Go binary in the world? It’s better to have the binaries produce one format and then let tools that need other formats wrap the program in a converter. Then if you need to change a detail of the new format, you only need to change the converter, not every Go binary in the world.
An analogy would be how go test -json does not actually put JSON-generating code in the test binary. It pipes the test output through a converter program (go tool test2json).
Based on the discussion above, this seems like a likely decline.
The argument that the perfect should not be an enemy of the good is sound, but it applies equally well to saying that we shouldn’t change anything. After all, the stack backtrace format is quite regular, and there is already existing code that parses it successfully.
Programs can fail in various ways. A panic is just one of them. For example, there are also various unrecoverable runtime errors. And of course a third party library could call
os.Exit.I think that if you want to make this reliable, you will need to wrap the program with a small helper that can collect the output and format it as you like. That could handle all cases and will work today.
If you want to continue this proposal, please make specific suggestions for how the ABI should be changed. However, personally I think it is unlikely that such a proposal would be accepted.
Thanks.