As Rob Pike said, if you don't let the real reason behind "panicing" die, then recovering is most logical thing to do in times of dire need!
For instance, the Caddy server routinely uses *recover* to recover from panics but responsibily logs them during ServeHTTP because it has to provide ultimate reliability while depending upon plethora of third party middleware! https://github.com/mholt/caddy/blob/master/caddyhttp/httpserver/server.go#L287 On Tue, Apr 25, 2017 at 6:59 PM, Sam Whited <s...@samwhited.com> wrote: > On Mon, Apr 24, 2017 at 10:06 PM, Kevin Conway > <kevinjacobcon...@gmail.com> wrote: > > In this example we're considering panic as a mechanism of preventing > > otherwise avoidable code bugs. What happens when the same code begins > > silencing panics and continuing on? > > Then the application author has explicitly said "I don't care what > happens, just keep running" and it becomes their problem. > > The "default" action if an application developer does nothing with > idiomatic errors is that those errors are ignored (but of course, they > can choose to handle them), the "default" action with panics is that > the program crashes (or they can choose to supress them). Sometimes, > although perhaps rarely in a library, that's what you want. > > —Sam > > -- > 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. > -- 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.
