> They do this because if your server code makes a mistake This is neither good or best practice. My take: - Know that there are simple-mistake panics, and i

> They do this because if your server code makes a mistake This is neither good or best practice. My take: - Know that there are simple-mistake panics, and internal-state-just-went-bonkers panics. For the latter, you can guess the boundary of impact (one request, one connection, one job, one userID, one process, ...) but exit(1) is much more reliable than guessing. - Tests can easily catch simple mistakes like accessing a nil pointer. - Know that the kind of programmer who does not care about simple tests, will also not care about concurrency bugs which introduce the more dangerous types of state corruption. This corruption would likely be not limited to a single request. Good luck to frameworks who assume that nothing bad would happen if they ignore a panic and continue serving more requests.