I don't understand how to implement this. When you start a new goroutine, the old goroutine keeps running. If the new goroutine panics, we can't panic in the old goroutine. It may not even exist anymore.

Or perhaps you are looking for something like GODEBUG=tracebackancestors=100? Search for tracebackancestors in https://golang.org/pkg/runtime/.

I think the real feature you're asking for is a way to set a handler that runs before the program exits, even when the program is aborting due to an unhandled panic.

FWIW, while support for atexit handlers has been intentionally omitted because they are so often misused, I found myself wanting one today for https://golang.org/cl/179599--it would be nice if the testing package had a chance to clean up and display output when a goroutine started by a test (as opposed to the test goroutine itself) triggers a panic.

@neild I think that's a fairly good description. I would love the ability to clean up the DB after a test panics, instead of having to go clean it manually when someone Fs* something up so that the defer doesn't run.

@ianlancetaylor I'm looking into tracebackancestors now and what kind of performance hit that brings.

My thought on implementation would be to add a PanicHandler somewhere around here: https://github.com/golang/go/blob/master/src/runtime/panic.go#L887 - it could no-op by default. Then I could call runtime.RegisterPanicHandler(someFunc) up in my main() function.

There is no reliable way to run a hook when the program exits. And such a hook would run in a very limited environment, so it would be difficult to write a correct hook.

If you must do some sort of cleanup after a program exits, the only reliable mechanism is to execute the program as a child, and do the cleanup after it returns.

@ianlancetaylor Doesn't literally every unrecoverable panic call runtime.fatalpanic which is ultimately what writes the panic to stderr and exits 2? If so, it would be something like:

if runtime.HasRegisteredPanicHandler() {
  handle := runtime.GetRegisteredPanicHandler()
  handle()
}

If you are cleaning up a database, vs logging an error msg, you should do that on startup, as no exit code will run on OS crash or power-off.

We can reliably hook into when a panic is going to cause the program to exit, but that is not the same as reliably hooking into every case where a program exits. There are many exit paths that do not go through runtime.fatalpanic.

And my other point still holds: by the time we reach runtime.fatalpanic the runtime has started shutting down. Any hook called by fatalpanic can not run ordinary Go code. It can only run a carefully written subset of Go code.

@networkimprov Yup - and that's what we do - we run a clean-up both in setup() and in a defer() block, just in-case tests panicked. It's not DRY, but it's robust.

@ianlancetaylor That may not have been clear, sorry - I only want it to run in the case of a panic, that's the only time, not on other exit paths. Other exit paths can all be easily handled normally.
I do kind of see what you're talking about now, where the stack isn't necessarily in a predictable state here. I figured that anything generic you could do in a recover() function, you could do here (e.g. forward the panic message to an external logging service). I don't know how much the stack unwinds before we get here - would something like a logger still be available as long as:

• the logger itself didn't cause the panic and
• was instantiated prior to the function that panicked?

Would you happen to feel any differently about this if the proposed destination for this handler's home was say...in the unsafe package?

You can write anything in a deferred function. The deferred functions are invoked as the stack is unwound.

A fatal panic shuts down the whole runtime, including the scheduler and everything.

I'm not sure I see the purpose of only handling a panic. You can write that yourself, with some care, using defer statements. But why distinguish between a panic and a fatal runtime error? A fatal runtime error is something like running out of memory; it doesn't panic, doesn't run defer statements, but just crashes the program with a stack trace. I don't think it's a common case to want to handle a uncaught panic but not want to handle a fatal runtime error.

I personally would not feel differently if this were in the unsafe package.

The two things we personally do with a panic -
a) iterate a prometheus error counter
b) send the panic as a log message to Splunk
I'm able to accomplish b) by moving the logging responsibility out of Go and into another daemon but a) cannot be accomplished without copy+pasting the exact same code into literally thousands of functions, and even copy+pasting that code every where, I still can't run either a) or b) when there's a panic from a 3rd party library.
When there's a panic from a 3rd party library, we find an alternate library or submit a patch to address the panic, but it's very hard to get at that panic error message in general. That's why we (and other users) end up using https://github.com/mitchellh/panicwrap or https://github.com/bugsnag/panicwrap, so that we can iterate the counter and send the log message. I've seen others handle it with a post stop kubernetes hook and they go find/grep the log looking for a panic message.
I'm looking to imitate the behavior that panicwrapper provides. I'm assuming* that those are fatal panics (as opposed to a different kind of panic). I just think having a language native method of handling those unexpected failures from 3rd party libraries would be super helpful

In general Go has taken the position that error recovery should either be done locally (that is, by a parent frame expecting a certain kind of panic in the child) or else in a separate process entirely. This is why you can't recover from panic across goroutines and you also can't recover from throw (runtime-internal detection of very bad conditions like possible memory corruption).

We could have a kind of global defer to push something onto the top of every goroutine before it starts, but it's unclear that would help more than it complicates things. In the end you still need another process (one that can't be affected by memory corruption, stuck locks, or whatever other issues might have triggered the panic) watching the Go program if you want to be completely robust.

Marking as LanguageChange because this is about a fundamental language issue, even if the end result is mainly implemented in the runtime. The spec would need to explain that there is this "final step" during a panic.

Per comments above, we aren't going to add this to the language/runtime. It would require defining a subset of Go that could be run in the panic handler to avoid effectively relaunching goroutines as the program was exiting. For Go, as with many other languages, reliable error handling has to be done in a separate process.

I don't understand your comment about prometheus error counters; in particular I don't understand why the code has to be copied into thousands of functions. Perhaps there is some way that can be addressed short of a fatal panic handler. For example, perhaps the separate analyzer process could examine the stack trace. But I don't really know.

-- iant for @golang/proposal-review