> Yes, and then crashes the program. In the scenario I described, with > thousands of other requests in flight that meet an abrubt end. That could be > incredibly costly, even if it's been planned for
There are a host of other reasons that can take a server offline abruptly. It seems like a odd misallocation of resources to try to prevent one specific case - a goroutine panics due to a programming error or input validation failure -- both which are far better addressed with testing. To try to postpone the exit of a program after a critical error to me implies a much more complex testing and validation process that has identified all the shared state in the program and verified that it is correct in the case that a panic is caught. To me it seems simpler and more likely to have the root cause of the panic addressed to just let the program crash. The alternative, somehow firewalling the crash, and its effects on the internal state of your program, sounds unworkably optimistic. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
