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.
