Recover/panic need not be used only in case of a “critical” error. Just as in the case of setjmp/longjmp, there are other useful patterns. For example, a user may ask an interpreter to abandon its current computation by typing ^C. This would be handled by a longjmp/panic() to regain control at the REPL level.
There are actually at least three use cases: 1. Reduce the "semantic clutter" of having to check error return at every level just because a very deeply nested function may fail 2. Regain control as above in case of cancellation. 3. Indicate a critical error. For 1. (IMHO) the best mechanism was Pascal’s non-local goto. It *only* returned control higher up in the stack and to a lexically enclosing function - this could be checked at compile time. In Go panic/recover are analogs of longjmp/setjump and compile time checking is not possible to ensure that panic doen’t escape a package scope. Also, Go allows lexical nesting of unnamed functions but not named ones so one would not write, e.g. a parse() function as one giant function with multiple sub functions, one each for a parse rule. And concurrency complicates things. > On Apr 25, 2017, at 7:52 PM, Dave Cheney <d...@cheney.net> wrote: > >> Yes, and then crashes the program. In the scenario I described, with >> thousands of other requests in flight that meet an abrubt end. That could >> be incredibly costly, even if it's been planned for > > There are a host of other reasons that can take a server offline abruptly. It > seems like a odd misallocation of resources to try to prevent one specific > case - a goroutine panics due to a programming error or input validation > failure -- both which are far better addressed with testing. > > To try to postpone the exit of a program after a critical error to me implies > a much more complex testing and validation process that has identified all > the shared state in the program and verified that it is correct in the case > that a panic is caught. > > To me it seems simpler and more likely to have the root cause of the panic > addressed to just let the program crash. The alternative, somehow firewalling > the crash, and its effects on the internal state of your program, sounds > unworkably optimistic. > > -- > 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.
