Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: net/http: don't recover from handler panics #25245
The http package recovers from panics in handlers, logs a stack trace, and continues. We should consider removing the recover and letting the process crash in the event of a handler panic.
A panic (other than ErrAbortHandler) indicates a bug in a handler. There is no guarantee that the handler has properly cleaned up after the panic. It is very possible that the panic has left the server in an inconsistent state; e.g., mutexes left locked. Crashing the process surfaces the problem to the user immediately and allows it to be restarted.
As a concrete example of this, I'm looking into a bug where a handler crashed in code that tracks request statistics and left a mutex locked. Future requests blocked on this lock, piling up deadlocked goroutines. We'd have been much better off if the process had simply crashed and been restarted.
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.