If memory serves, recovery is new; the behavior you are looking was the previous behavior.

As to your situation, use the following rule of thumb:

l.Lock()
// Action can't panic.
l.Unlock()

// or

l.Lock()
defer l.Unlock()
// Action that can panic.

If you're offering advice on how not to deadlock on panic, then just not writing code which panics in the first place seems even better. And yet bugs of all kinds do seem to still happen. :)

This has come up previously and IIRC the resolution was that it's regrettable but we can't change it in Go 1.x for compatibility. So this is probably a Go 2.x thing.

Agreed that we can't change it now; I was thinking of go2 when I filed this.

Not a fan of this proposal. We're talking about unexpected panic's, not panic's which have come up in development and been ignored... There's no reason to unexpectedly bring down someone's production server because of such a panic which, in all likelihood, would be caused by an unusual http request (hacking attempt, et al). I do agree it should be a configurable option in the server to disable automatic recovery, though.

"There is no guarantee that the handler has properly cleaned up after the panic."

There's never a guarantee people are cleaning up correctly, panic or not. If they are defer'ing their cleanup's, there's no problem.

@bradfitz, why can't this feature be changed in Go 1.x? Isn't is possible to add a new field to the Server type, like ShutdownOnPanic? The default is false so there should be no API change.

I think that a server should be shutdown in case of a panic. It is responsibility of the supervisor process to restart the Go application.
I currently use systemd, but in future I'm planning to use Nginx Unit, that should make the deployment of a Go application more robust, even with ShutdownOnPanic set to true.

Folding this into #5465.