On Wednesday, 26 April 2017 10:57:58 UTC+10, Chris G wrote: > > 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 > > panic does that
> > - remove itself from a load balancer > > your load balancer should detect that; it shouldn't wait to be told that a backend has failed. > > - > - alert some monitoring program that it has experienced critical errors > > The monitoring program should detect that the process exited; not the other way around. > > - depending on widespread severity, have a monitoring program alert a > human to inspect it > > Same; relying on a malfunctioning program to report its failure is like asking a sick human to perform their own surgery. > 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.
