runtime: control panic behaviour programmatically #21777
Comments
mdempsky
changed the title
|
Note that in the general case we can not run user code on program error. You cite #21376, but as far as I can see the example there is not a panic, it's an exception. An exception can not in general be recovered, so it's not clear that it matters that it was run on a library goroutine. That is, even if we provided a way to recover a panic on any arbitrary goroutine, for an exception that recover would never be run anyhow. So fixing that will not fix your real problem. I think the only general way you can do what you want is to use a small wrapper program that starts your real program and handles the stack trace. I'll leave this open for now but I suspect we're going to close this without taking any action, since any fix we make will be only partial. |
|
It appears there was no support for doing this, so I'm closing this issue. |
What version of Go are you using (
go version)?go version go1.9 windows/amd64(latest)What operating system and processor architecture are you using (
go env)?What did you do?
If my application panics unexpectedly, Go produces a stack trace output, which is very useful for me to debug the issue.
However, I have an application that ships to end users. The stack trace is a technical document, not an end-user call to action.
What did you expect to see?
I have worked around this issue by adding a
recovercall in almost all of my goroutine invocations, that calls a common function to capture the stack trace and format it in a non-technical way. e.g. "please send the following message to your support contact: base64(gzip(panic data))"What did you see instead?
Today in #21376 i ran across a panic in a goroutine started by the standard library. The full stack trace was displayed against my intention.
I obviously have no way of inserting a
recovercall into such a goroutine (well, except for patching all ofstd).I would like a better way of controlling the panic, for all goroutines, without needing to insert
recovercalls and with support for panicking goroutines the standard library.I am aware of
GOTRACEBACK=nonebut i really do want these stack traces, in all cases. I just need them to be handled in a custom way.The text was updated successfully, but these errors were encountered: