On Wed, Apr 26, 2017 at 3:07 AM, Dave Cheney <d...@cheney.net> wrote:
> > > 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 > No, panic certainly does not do that. It prints the stack trace. A proper logger could add additional information about the program state at the point of the panic, which is not visible from the stack trace. It also might at least be reasonable to perform an auto-save before quitting. Same; relying on a malfunctioning program to report its failure is like > asking a sick human to perform their own surgery. > What makes you think that a panic implies that the whole program is malfunctioning? A panic should certainly taken seriously, and the computation in which it happened should be aborted. But if you think of a functional programming style, there are clear points in the call tree, at which the recover could happen and the the computation can safely aborted without impacting the rest of the program. If you think of any multi-user software, at worst you can kill the session for a user, but do not necessarily have to impact the other users. Best regards, Peter -- 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.
