> I cannot conceive of the scenario where it makes sense to recover a bounds-checking induced panic. A bog-standard HTTP server (or likely any kind of request-

> I cannot conceive of the scenario where it makes sense to recover a bounds-checking induced panic. A bog-standard HTTP server (or likely any kind of request-serving daemon). If a client causes a bounds-checking panic, I do not want that to crash the entire server. It's not even really particular to bounds-checking. If I push a change that causes a nil pointer dereference on a particular handler, I would vastly prefer that it 500's those specific requests rather than crashing the entire server every time it happens. The Go HTTP server does this internally (though there is talk about not doing it, deferred til Go 2 https://github.com/golang/go/issues/5465 https://github.com/golang/go/issues/5465). > The process should crash; the alternative is to continue operating in an unknown, irrecoverable, and potentially security compromised state. The goroutine should probably crash, but that doesn't necessarily imply that the entire program should crash. For some applications the process and the goroutine are one and the same, but that's not universally true. A lot of applications have some kind of request scope where it's desirable to be able to crash the thread a request is running on without crashing the entire server.