I think those are all excellent things to do. They do not preclude the use of recovering from a panic to assist (emphasis on assist - it is certainly no silver bullet) in achieving fault tolerance.
Assuming a web service that needs to be highly available, crashing the entire process due to one misbehaved goroutine is irresponsible. There can be thousands of other active requests in flight that could fail gracefully as well, or succeed at their task. In this scenario, I believe a well behaved program should - clearly log all information about the fault - remove itself from a load balancer - alert some monitoring program that it has experienced critical errors - depending on widespread severity, have a monitoring program alert a human to inspect it On Tuesday, April 25, 2017 at 3:32:56 PM UTC-7, Dave Cheney wrote: > > Aside from arguments about using panic/recover to simulate longjmp inside > recursive descent parsers I can think of no valid reason why recover should > be used in production code. > > Imo, the arguments about wrapping all goroutines in a catch all recover > are solving th wrong problem. > > - if third party code you use panics regularly, maybe don't use it, or at > least validate inputs passed to it to avoid provoking it. > - if your program needs to be available, then rather than trying to > diagnose the program's state internally, use something like daemontools, > upstart, or systemd to restart it if it crashes. Dont forget there are > plenty of other ways to exit a go program abruptly; os.Exit or log.Fatal > are two that come to mind. Prefer only software. > - if your program has to be highly available, then abandon the falsehood > that a single machine can meet these requirements and invest your > engineering effort in making your application run across multiple machines. > > IMO there is no justification for using recover as a general safety net in > production Go code. -- 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.
