`panic/recover` are really bad names for setjmp/longjmp. `throw/catch` are much closer.
And C has `assert`. You may set handler for SIGABRT, but then you have to know what are you doing. Usually it is set for backtrace printing only. I mean: usual languages has clean separation between "wrong state or input", "fast control flow" and "fatal" errors. C has "return code + errno" for first, "setjmp/longjmp" for second and "assert" for third. Languages with exceptions have exceptions hierarhy with documented support from runtime for "fatal exceptions". Some languages choose process isolation for recovering from fatal error (php, erlang... .Net has domains, but looks like .Ney Core doesn't). Go has "return error" for first, abuses "panic/recover" for second, and in absence of true process isolation, simply has no choice for "fatal error". Go should have choice for "fatal error". Since many people want to recover from "fatal error" (and this thread shows it clearly), Go should have true "process isolation". But it is just a dream. 26 апр. 2017 г. 8:35 AM пользователь "Bakul Shah" <ba...@bitblocks.com> написал: > 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/rW6LB-9N37I/unsubscribe. > To unsubscribe from this group and all its topics, 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.
